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This publication describes the ibm 7090/7094 ibjob Processor, 
a subsystem of the 7090/7094 ibsys Operating System, Version 13. 
The ibjob Processor, 7090-PR-929, translates programming lan- 
guages. It consists of the following components: 

Processor Monitor (ibjob) -7090- SV-801 

Fortran iv Compiler (ibftc)— 7090-FO-805 

cobol Compiler ( ibcbc ) -7090-CB-806 

Macro Assemblv Program ^ibmap^— 7090-SP-804 

Loader (ibldr)-7090-SV-802 

Subroutine Library ( iblib ) -7090-LM-803 

Debugging Processor (ibdbl)-7090-PR-807 

This publication is divided into three parts. The first part de- 
scribes the procedures for the applications programmer to follow 
in using the system. The second part describes the operations of 
each component for use by the systems programmer. The third 
part contains the text of all the error messages for each component 
with the appropriate explanations. 










Preface 



This publication provides procedural information for 
using the ibm 7090/7094 ibjob Processor in the follow- 
ing capacities: compiling, assembling, loading, execu- 
tion, and debugging. The primary objective of this 
publication is to help the reader to use these capa- 
bilities efficiently. For this reason, the organization, 
layout, and reference aids (diagrams, flowcharts, ap- 
pendixes, and cross-references ) are designed to follow 
a job-processing sequence. 

This material is divided into three parts. The first 
part contains instructions for the Fortran iv, cobol, or 
map programmer. It gives the basic information re- 
quired to run a job. Once the programmer has be- 
come familiar with this material, he can use the control 
card checklists in the appendixes for quick reference. 

The second part contains a more detailed explana- 
tion of the operations and functions of the various 
components for the programmer who is responsible for 
modification and maintenance of the system. 
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sages generated by the ibjob Processor, with explana- 
tions for all messages that are not self-explanatory. 

It is not necessary that each reader cover all of the 
material in this manual. For example, the Fortran iv 
programmer need only be concerned in the first part 
with the Processor Monitor, the Fortran iv Compiler, 
and the Subroutine Library sections. He can then find 
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additional information in the respective sections of the 
second part of the publication. 

The reader should be familiar with the publication 
that describes the particular language he is using. 
These publications are: 

IBM 7090/7094 IBSYS Operating System, Version 13: 
FORTRAN IV Language, Form C28-6390. 

IBM 7090/7094 IBSYS Operating System, Version 13: 
COBOL Language, Form C28-6391. 

IBM 7090/7094 IBSYS Operating System, Version 13: 
Macro Assembly Program (MAP) Language, Form 
C28-6392. 

The programmer who wants to use the ibjob debug- 
ging facilities should read the publication IBM 7090/ 
7094 IBSYS Operating System, Version 13: IBJOB 
Processor Debugging Package, Form C28-6393. 

The map programmer should be familiar with the 
contents of one of the following publications: IBM 
7090 Principles of Operation, Form A22-6528; or IBM 
7094 Principles of Operation, Form A-22-6703. The 
map programmer who uses the Input/Output Control 
System should also read the Publication IBM 7^9^ / 
7094 IBSYS Operating System, Verson 13: Input/Out- 
put Control System, Form C28-6345. 

All readers should be familiar with the contents of 
the publication IBM 7090/7094 IBSYS Operating Sys- 
tem, Version 13: System Monitor (IBSYS), Form 
C28-6248. 

The machine configuration required for the opera- 
tion of the ibjob Processor is described in Appendix G. 



Copies of this and other IBM publications can be obtained at IBM Branch Offices. 

Address comments concerning the contents of this publication to: 

IBM Corporation, Programming Systems Publications, Dept. D91, 1271 Avenue of the Americas, New York, N. Y. 10020 



©International Business Machines Corporation, 1C65 



Contents 



Part 1: Programming Fundamentals 5 

Introduction 5 

Control Card Format 5 

Core Storage Allocation 6 

IBJOB Processor Dictionaries 6 



Processor Monitor 8 

System Monitor Control Cards 8 

$JOB Card 8 

$EXECUTE Card 8 

IBJOB Processor Control Card 8 

$IBJOB Card 8 

Component Control Cards 10 

End-of-File Card 10 

Optional Control Cards 10 

$IBSYS Card 10 

$ID Card 10 

$STOP Card 10 

$PAUSE Card 10 

$* Card 10 

$ENTRY Card 10 

$DATA Card 1 

$ENDREEL Card 1 

$POST Card 1 

$IBREL Card 1 

$TITLE Card 1 

Input/Output Control Cards 1 

Input/Output Editor 1 

$IEDIT Card 1 

$OEDIT Card 13 

Altering an Input Deck 14 

Sample Deck Format Using an Alternate Input Unit ... 15 

FORTRAN IV Compiler (IBFTC) 17 

$IBFTC Card 17 

Sample FORTRAN IV Deck Format 18 

COBOL Compiler (IBCBC) 19 

$IBCBC Card 19 

$CBEND Card 20 

Debugging for COBOL Programs 20 

Sample COBOL Deck Format 20 

Macro Assembly Program (IBMAP) 22 

$IBMAP Card 22 

Sample MAP Deck Format 24 

Debugging Package 25 

Compile-Time Debugging 25 

$IBDBC Card 25 

Load-Time Debugging 25 

$IBDBL Card 25 

*DEND Card 26 

Postprocessor Routines 26 

Sample Load-Time Debugging Deck Format 26 

Relocatable Binary Decks 28 

Column Binary Format 28 

Loader (IBLDR) 29 

Object Program Files 29 

Loader Name Conventions 29 

Component Control Card for the Loader 31 

$IBLDR Card 31 



Loader Control Cards 31 

$FILE Card 31 

$LABEL Card 34 

SPOOL Card 35 

$GROUP Card 35 

$USE Card 36 

4>/-\\ftrri r> l qo 

<BVyM± 1 VjcUU o\j 

$NAME Card 36 

$SIZE Card 36 

$ETC Card 36 

Input/Output Buffer Allocation 37 

General Buffer Assignment 37 

Buffer Assignment with $POOL and $GROUP Cards 37 

Unit Assignment 38 

Unit Assignment Notation 38 

Unit Assignment Specifications 38 

Intersystem Unit Assignment 38 

Order of Assignment 38 

rv.rf>,.l.-.,7 ir^ Q f,, r « f 4-V.^ t ««J~,. on 

wona) j. c^rfluic; o± nit^ j^iuaud ijc? 

The Overlay Structure 39 

Overlay Control Cards 41 

$ORIGIN Card 41 

$INCLUDE Card 42 

CALL Transfer Vector 44 

$ENTRY Card with Overlay 44 

Subroutine Library (IBLIB) 45 

FORTRAN Mathematics Library 45 

Calling Sequences to FORTRAN IV Mathematics 

Subroutines 45 

Error Handling for FORTRAN IV Mathematics 

Subroutines 46 

Floating Point Trap Subroutines 46 

7090 Double-Precision Simulation 47 

Evaluating Accuracy 47 

Subroutine Reference Tables 47 

FORTRAN Utility Library 49.3 

Machine Indicator Test Subroutines 49.3 

Dump Subroutine 49.3 

FORTRAN Files 49.4 

Constant Units 49.4 

Variable Units 49.4 

Programming in Sections 50 

Examples of Programming in Sections 50 

Grouping FORTRAN Source Decks 50 

COBOL-FORTRAN Program Adjustments 50 

Part 2: System Programmer's information 53 

Processor Monitor Information 53 

Job Control Operations 54 

ACTION Routine for Calling IBJOB Components 54 

Process Control Operations 56 

Initialization of the Input/Output Editor 56 

Control Card Search 56 

Process Control Option Scan 57 

Process Control Error Procedure Routine 58 

Input/Output Editor Operations 58 

IOEDIT Routine 58 

Input Editor 58 

Output Editor 58 

Punch Editor 59 

IBJOB Processor Maintenance Cards 59 

$DUMP Card 59 

$PATCH Card 60 



FORTRAN IV Compiler Information 62 

Structure of the FORTRAN IV Compiler 62 

Phase A 63 

Phase B 65 

Assembly Processing 65 

Internal Formula Number ( IFN ) Generation 65 

Internal Instruction Formats (IIF's) for Main File. ... 66 

Internal Instruction Formats ( IIF's ) for Dotag File .... 66 
Internal Instruction Formats (IIF's) from Relcon 

Analysis Routine 66 

Table Handling 67 

Diagnostic Handling 67 

Preliminary Error Handling 67 

Error Message Processor Action 68 

COBOL Compiler Information 69 

SEGMENT I 69 

The COBOL Supervisor 69 

General Purpose Subroutines 69 

File and Table Control Blocks 70 

Transfer Table 70 

Communication Words 70 

SEGMENT II 70 

ENVIRONMENT I 70 

DATA I 71 

DATA II 71 

PROCEDURE I 71 

PROCEDURE II 71 

ENVIRONMENT II 71 

DATA III 71 

PROCEDURE III 72 

Subscript Calculations 73 

Treatment of Incoming Procedure-Names at Point of 

Definition 73 

Computation of Variable Lengths 73 

Instruction Generators 73 

Cleanup 73 

Assembler Information 74 

Assembler Design 74 

Phase 1 74 

Initialization 74 

Pass 1 75 

Phase 2 76 

Interlude 76 

Pass 2 77 

Load-Time Debugging Processor Information 79 

Load-Time Debugging Operations 79 

Debugging Compiler Routines 80 

Debugging Actions by the Assembler 80 

Debugging Actions by the FORTRAN Compiler 80 

Debugging Actions by the Loader 80 

Execution Time Routines 80 

Postprocessing: The Editor and Translator Routines ... 81 

Loader Information 82 

Absolute Address Assignment 82 

Program Loading 83 

Library Subroutines 83 

Input/Output Environment 83 

Overlay 83 

Load-Time Debugging 83 

Communications from the Loader 83 

Configurations of the Loader 83 

Loader Operations 84 

Initialization 84 

Section 1 84 

Section 2 86 

Section 3 88 

Section 4 89 

Section 5 91 

Control of Program Execution 91 

External Storage for Text 92 



Loader Input 93 

Load File Binary Cards 94 

Even Storage Feature 98 

Subroutine Library Information 100 

System Subroutines 100 

FORTRAN IV Input/Output Library 101 

Standard FORTRAN IV Input/Output Package 102 

Alternate FORTRAN IV Input/Output Package 104 

Correspondence Between FORTRAN Symbolic Units and 

System Files 105 

FORTRAN IV Utility Library 107 

COBOL Subroutines 108 

MOVPAK Subroutines 108 

COBOL Input/Output Subroutines 116 

Additional COBOL Subroutines 118 

Librarian 122 

Subroutine Library Maintenance 122 

Librarian Control Cards 122 

$EDIT Card 122 

$REPLACE Card 122 

$ASSIGN Card 123 

$INSERT Card 123 

$AFTER Card 123 

$DELETE Card 123 

Restrictions Using Disk 123 

Restrictions Using Drum 123 

Part 3: IBJOB Processor Error Messages 124 

IBJOB Monitor Error Messages 125 

FORTRAN IV Compiler Error Messages 127 

COBOL Compiler Error Messages 134 

Assembler Error Messages 145 

Load-Time Debugging Processor Error Messages . . 149 

Loader Error Messages 151 

Subroutine Library Error Messages 158 

Appendixes 163 

Appendix A: Control Card Format Index 163 

Appendix B: Control Card Check List 169 

Appendix C: IBJOB Communication Region 170 

Appendix D: Sample Control Card Deck 172 

Appendix E: Procedure for Selecting the 7094 
Optional Conversion Routine 173 

Appendix F: Core Storage Load Map 174 

Appendix G: Machine Configuration Required for 
IBJOB Processor Operation 175 

Appendix H: FORTRAN IV Mathematics 

Subroutines— Algorithms, Accuracy, and Speeds .. 176 

Single-Precision Subroutines 177 

Double-Precision Subroutines 190 

Complex Subroutines 195 

Miscellaneous Subroutines 198 

Appendix I: Storage Requirements for FORTRAN IV 
Mathematics Library Subroutines 200 

Appendix J: Procedure for Using the 7090 

Asterisk Deck 201 

Glossary 202 



PART 1: PROGRAMMING FUNDAMENTALS 



Introduction 



The ibjob Processor is one of several system programs 
operating under the ibm 7090/7094 ibsys Operating 
System. These programs operate under the control of 
the first-level monitor, the System Monitor (ibsys). 

The ibjob Processor is a versatile monitored system 
that can translate several source language program 
decks within a single job. It can compile, assemble, 
load, and execute program decks written in the 
Fortran iv, cobol, and/or map languages. It can also 
load and execute previously assembled object pro- 
gram decks. In addition, program decks written in dif- 
ferent programming languages can be combined with 
previously assembled decks to form a single executable 
object program. Finally, a debugging program aids in 
program checkout. 

A program deck is a series of card images headed by 
a control card that calls a component to translate the 
deck, and ended by a control card that transfers control 
back to the ibjob Monitor. Any number of program 
decks can be run at one time. Some may operate like 
closed subroutines or subprograms. All these decks 
grouped together can form a Processor application, 
which is the basic unit of work that can be performed 
by the ibjob Processor. In processing an application one 
or more operations may be performed, such as com- 
pilations, assemblies, or the loading of relocatable pro- 
grams that were previously assembled. 

Figure 1 illustrates the operation of the ibjob Proc- 
essor on source language programs. The following 
seven components may be used in these operations : 

1. The Processor Monitor (ibjob), which is the su- 
pervisory component of the ibjob Processor. The Mon- 
itor provides communication with the ibsys Monitor, 
positions the system tape, brings the various compo- 
nents into storage according to processing require- 
ments, and regulates the input/output phasing of the 
components. 

The Processor Monitor reads control cards that spec- 
ify the actions to be performed in a Processor applica- 
tion. 



2. The fortrak iv Compiler (ibftc), which com- 
piles and assembles programs written in the Fortran iv 
language. It produces input to the Loader. 

3. The cobol Compiler (ibcbc), which compiles 
programs written in the cobol language and produces 
input to the Macro Assembly Program. 

4. The Macro Assembly Program (ibmap), which 
processes map language source programs and map pro- 
grams produced by the cobol Compiler, and produces 
input to the Loader. 

5. The Debugging Package, which allows the pro- 
grammer to obtain dumps of specified areas of core 
storage and machine registers during program execu- 
tion for the purpose of debugging a program with a 
minimum of programming effort. Two separate facil- 
ities are provided: compile-time debugging for cobol 
programs (ibdbc) and load-time debugging (ibdbl) 
for Fortran iv and map language programs. 

6. The Loader (ibldr), which processes and com- 
bines several relocatable binary programs to form one 
absolute binary object program. The Loader loads 
separately assembled program segments combined 
with any required subroutines from the Subroutine 
Library, allocates core storage for common data and 
input/output buffers, generates necessary initialization 
sequences for program use of input/output operations, 
and provides a listing of core storage allocation. 

7. The Subroutine Library (iblib), which contains a 
group of relocatable subroutines available for system 
and programming use. Subroutines may be edited 
through the Librarian. 

Control Card Format 

The following control card notation is used in the 
control card formats throughout this publication: 

1. Upper-case letters must be punched exactly as 
shown. 

2. Lower-case letters indicate that a substitution 
must be made. 

3. Braces { } indicate that a choice of the contents 
is mandatory. 
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Figure 1. Operation of the ibjob Processor on Source Language Programs 



4. Brackets [ ] contain an option that may be omitted 
or included by the programmer. 

5. Options that are underlined are the standard op- 
tions. When no option is specified on a control card, 
the Processor uses the standard option. 

6. Commas are used to separate options. Embedded 
blanks should not be used. 

7. Except where noted specifically, the options on 
a control card may be punched in any order. 

Core Storage Allocation 

The core storage arrangement of the ibjob Processor 
components is illustrated in Figure 2. The location of 
the object program during execution is also shown. 

IBJOB Processor Dictionaries 

The Loader is able to combine decks coded in different 
source languages by using dictionaries common to all 
the decks. Control dictionaries, assembled by the map 
Assembler and the fortban iv Compiler, contain 
deckname entries and control section name entries. 
File dictionaries contain file names. 

Deck Names 

A deck name identifies a deck produced by either the 
Fortran iv Compiler or the Assembler from one 



source language. The programmer defines a deck name 
by punching it on a component control card (see 
"sibftc Card," "sibcbc Card," and "sibmap Card"). A 
deck name may be used to identify or qualify control 
section names within a deck. The use of deck names 
and the rules for forming deck names are described 
under "Deck Name Rules." 
Control Section Names 

A control section name refers to an area of coding or 
data within a program deck. These areas, called control 
sections, can be referred to by other decks. 

The cobol and Fortran iv Compilers make up con- 
trol section names for the programmer during process- 
ing. The map programmer designates control section 
names using the contrl and entry pseudo-operations. 
The rules for creating map control section names are 
listed under "Control Section Rules." Control sections 
may be renamed, replaced, or deleted at load time 
( see "Loader Control Cards" ) . 
File Names 

File names identify files used by a program. The map 
programmer creates file names using file pseudo- 
operations or the sfile card. The Fortran programmer 
uses the file routines. The cobol user describes a file 
by making a file description entry in the Data Division. 
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Figure 2. Core Storage Allocation of the Operating System Components 



The rules for making up file names are listed in the 
section "File Name Rules." 



Additional Index Register Mode 

The ibjob Processor always operates in the additional 
index register mode. It enters this mode upon receiving 
control from the ibsys System Monitor, and it leaves 
the additional index register mode before giving con- 
trol back to ibsys. Compilers operating under control 
of the ibjob Processor use the additional index register 
mode, and ibjob Processor obj'ect programs are 
normally executed in this mode. 

A compiled program may call a map language pro- 
gram that uses the multiple-tag mode. If this occurs, 



the map language must restore the additional index 
register mode, as well as all index registers used, before 
it returns control to the calling program. 

When a map language program that uses the 
multiple-tag mode calls a compiled program, the com- 
piled program automatically enters the additional 
index register mode. Thus, the instruction in the map 
language program immediately following the call to 
the compiled program should be to re-enter the 
multiple-tag mode. 

Floating-Point Trap Mode 

All programs compiled by the ibjob Processor operate 
in floating-point trap mode. The floating-point trap 
routine is loaded with every object program. 
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Processor Monitor 



The Processor Monitor is the major component of the 
ibjob Processor. Its primary function is to control com- 
munication between the System Monitor (ibsys) and 
the components of the ibjob Processor. The Processor 
Monitor is called into core storage when the ibsys 
Monitor reads a sexecute card on which ibjob is 
specified. 

System Monitor Control Cards 

The following ibsys System Monitor control cards may 
be required for an ibjob Processor application. 

$JOB Card 

The Processor Monitor transfers control to the resident 
portion of the System Monitor, called the Nucleus 
(ibnuc), when the Processor Monitor reads a sjob card. 
If system units have not been reassigned or made un- 
available during the last job and if a between-jobs inter- 
rupt condition does not exist, the Processor Monitor 
regains control and transfers control to the installation 
accounting routine. If there is no installation accounting 
routine, the sjob card is listed on both the system 
printer and the system output unit, where it causes a 
page to be ejected before listing of the card, and the 
Processor Monitor retains control. 

If units have been reassigned or made unavailable 
during the last job and/or if a between-jobs interrupt 
condition exits, the System Monitor retains control 
until a sexecute card is read. 

The format of the sjob card is : 

1 16 

$JOB any text 

Columns 16 through 72 are normally used to identify 
a job and may contain any combination of alphameric 
characters and blanks. The information is printed 
in the program listing as punched, but it has no effect 
on the program except as a match when a srestart 
card is used. ( See publication IBM 7090/7094 IBSYS 
Operating System: System Monitor (IBSYS), Form 
C28-6248. ) A deck name in columns 8-13 is printed in 
the listing, but has no effect on the program. 

$EXECUTE Cord 

The sexecute card specifies the ibsys subsystem to be 
used in processing a program. It must precede a Proc- 
essor application within a job if one of the following 
conditions exists : 

1. The Processor application is the first unit of work 
to be performed within the job. 



2. The previous Processor application resulted in 
execution of an object program. 

3. Another subsystem was in control. 

The Processor Monitor checks the subsystem name. 
If the name is ibjob, no action is taken. If the name is 
anything other than ibjob, this information is relayed 
to the ibsys Monitor. The Processor Monitor then 
transfers control to the ibsys Monitor. 

The format of the sexecute card is : 

1 16 

$EXECUTE subsystem name 

The subsystem name consists of six or fewer bcd 
characters beginning in column 16. 

IBJOB Processor Control Card 

The following control card is required for an ibjob 
Processor application. 

$/BJOB Card 

The sibjob card must be the first control card read by 
the Processor Monitor for a given application. The 
options specified in the sibjob control card determine 
the manner in which an application is to be processed. 

The format of the sibjob card is : 

1 16 

$IBJOB [, options] 

The options, which start in column 16, are described 
in the following text. 

Execution Option 



HnogoU 



go— The object program is executed after it is loaded. 

nogo— The object program is not executed, even if it 
is loaded. If this option is specified, the object program 
is loaded only when logic, dlogic, or map is specified 
in the sibjob card. 

If neither go nor nogo is specified, the object pro- 
gram is to be executed (go). 

Logic Options 

r( XOLOGIC )~[ 
b< LOGIC > 
LlDLOGIC /J 

nologic— A cross-reference table is not wanted. 

logic— A cross-reference table of the program sec- 
tions and of the system subroutines required for exe- 
cution is generated. The origin and length of each 
program section and subroutine, and the buffer as- 
signments, are also given. When this option is specified 
for a Subroutine Library editing execution, a listing 



of the control section dependencies in the generated 
library is produced. 

dlogic— A cross-reference table of the program sec- 
tions and of the origin and length of each program 
section is generated. The system subroutines and buffer 
assignments are not given if this option is chosen. 

If neither nologic, logic, nor dlogic is specified, a 
cross-reference table is not generated (nologic). 

MAP Options 



r < NOMAP ) 1 
LIMAP— \j 



nomap— A core storage map is not wanted. This map 
is also called "memory map" and "load map." 

map— A core storage map showing the origin and the 
amount of core storage used by the ibsys Operating 
System, the object program, and the input/output buf- 
fers is generated. The file list and buffer pool organiza- 
tion are also given. When this option is specified for a 
Librarian execution, a listing of all subroutines in the 
generated library is produced. A sample core storage 
map is shown in Appendix F. 

If neither nomap nor map is specified, a storage map 
is not generated (nomap). 

File List Options 

|" \ NOFILES ) 1 
L | FILES J J 

nofiles— A listing of the input/output unit assign- 
ments and mounting instructions to the operator are 
printed on-line. 

files— A listing of the input/output unit assignments 
and mounting instructions to the operator are printed 
on-line and off-line. 

If neither nofiles nor files is specified, the list is 
printed only on-line (nofiles). 

Input Deck Options 

r \ source n 

L'} NOSOURCE J J 

source— The application contains at least one com- 
pilation or assembly. 

nosource— The application contains only relocatable 
binary program decks. These decks are loaded from 
the system input unit. 

If neither source nor nosource is specified, it is as- 
sumed that a compilation and/or assembly is required 
in the application (source). 

Input/Output Options 

/IOEX \ 

(minimum) 

) BASIC ( 

) LABELS i 

(FIOCS I 

l_ ' ALTIO ' 

ioex— The object program uses the Input/Output 
Executor for trap supervision. The only iocs routine 
available is for on-line printing. 



minimum— The Minimum level of iocs is to be 
loaded with the object program. Internal files cannot 
be used. The following routines are available: 

.OPEN 

.CLOSE 

.READ 

.WRITE 

.BSR 

.READR I if IOCS has been assembled 

.RELES ) for disk or drum storage. 

basic— The Basic level of iocs is to be loaded with 
the object program. In addition to the Minimum level 

luuuiico, uabiKs \^%jxi\rCLi.iM> < 

.BSF 

.CKPT 

JOIN 

.REW 

.STASH 

.WEF 

labels— The Labels level of iocs is to be loaded with 
the object program. In addition to the Basic level rou- 
tines, the Labels level contains routines for label check- 
ing and preparation. 

noes— A reduced form of Minimum iocs is to be 
loaded for use by a Fortran iv program. 

altio— The Fortran Alternate Input/Output pack- 
age is to be loaded for use by a Fortran iv program. 

The Fortran iv programmer can best use altio 
when core storage is limited, input/output activity is 
low, or mixed mode files are required. Otherwise, fiocs 
should be used. If the Fortran iv programmer chooses 
no option, the Minimum level of iocs is loaded auto- 
matically. 

map programmers can choose iocs options according 
to the routines needed by their programs, although the 
Loader provides an additional check for all levels ex- 
cept altio. Normally, if an object program requires a 
more comprehensive level of iocs than that specified 
by the programmer, the Loader loads the required 
level. But if altio is specified for a Fortran program, 
and the program requires a higher level of iocs, altio 
is still loaded, and an error message is generated. 

Because the Loader automatically loads the correct 
level of iocs, the cobol programmer does not need to 
specify any level. The Loader also loads Random iocs 
with the object program, if the program contains a 
reference to a Random iocs routine. 

The levels of iocs are described in the publication 
IBM 7090/7094 IBSYS Operating System: Input/Out- 
put Control System, Form C28-6345. The two Fortran 
iv input/output packages, fiocs and Alternate Input/ 
Output, are described in the section "Subroutine Li- 
brary Information." 

Overlay Options 



El 



FLOW ) 
NOFLOW \ 



Processor Monitor 9 



flow— Execution of the object program is not per- 
mitted if the rules concerning references between links 
are violated. These rules are stated in the section "Over- 
lay Feature of the Loader." 

noflow— Execution is allowed even though the rules 
governing references between links are violated. 

If neither flow nor noflow is specified, execution of 
the object program is not permitted when the rules 
governing references between links are violated 
(flow). 

Component Control Cards 

Each component operating within the ibjob Processor 
has a unique control card that causes the Processor 
Monitor to load the component. These component 
control cards are: 

FORTRAN Compiler SIBFTC 

COBOL Compiler SIBCBC 

Macro Assembly Program $IBMAP 

Debugging Compiler ( Load-Time ) SIBDBL 

Debugging Processor ( Compile-Time ) SIBDBC 

Loader SIBLDR 

Subroutine Library ( Librarian ) $EDIT 

Each of these cards will be described in detail in 
the respective component section of this publication. 

End-of-File Card 

The end-of-file card is an ibm 1401 utility program con- 
trol card. The end-of-file card must be the last card 
in a Processor application. An end-of-file card is either 
a card with a 7 and 8 punch in card column 1 or any 
control card that causes a file mark to be written by a 
peripheral program. 

Optional Control Cards 

The following cards are optional System Monitor con- 
trol cards frequently used in an ibjob Processor 
application: 

$IBSYS Card 

The Processor Monitor prints the message 
RETURNING TO IBSYS 

on-line and transfers control to the ibsys System Moni- 
tor when the sibsys card is read. 
The format of the sibsys card is : 

1 

$IBSYS 

$ID Card 

The $iD card causes the Processor Monitor to transfer 
control to the installation accounting routine if one 
exists. The distributed version of the Operating Sys- 
tem does not contain an installation accounting routine. 
Therefore, the only action that occurs is the listing of 
the sid card. 



The format of the sid card is : 

1 7 

SID any text 

Columns 7-72 may contain any combination of alpha- 
meric characters and blanks. 

$STOP Card 

The sstop card transfers control to the System Monitor. 
In effect, the sstop card defines the end of a deck of 
jobs. 

The format of the sstop card is : 

1 

$STOP 

$PAUSE Card 

The spause card causes the machine to halt temporarily 
for operator action. 

The contents of the variable field of the spause card 
are printed on-line. The spause card allows the pro- 
grammer to interrupt processing for specific operator 
action. When the spause card is used, the variable field 
should contain explicit instructions to the operator so 
that immediate action can be taken. Processing is re- 
sumed when the operator presses the start key. 

The format of the spause card is: 

1 16 

SPAUSE instructions to the operator 

Columns 16-72 may contain any combination of 
alphameric characters and blanks. 

$* Card 

The $* card is a comments card. The contents are 

printed on-line and off-line. No further action occurs. 

The format of the s* card is: 

1 3 

S* any text 

Columns 3-72 may contain any combination of alpha- 
meric characters and blanks. 

$ENTRY Card 

The sentry card specifies the location of the initial 
transfer to the object program at execution time. The 
variable field contains an external name to which the 
initial transfer is to be made. If the sentry card is 
omitted or if the variable field is blank, the initial 
transfer is either to the standard entry point of the 
first deck retained or to an entry point whose name is 

" " (consists of six periods, the name compiled as 

the standard entry point to Fortran iv main programs ) . 
The format of the sentry card is: 

1 16 

SENTRY 



|~ \ Exname ) 1 
L ( Deckname \ J 



where the variable field contains either an external 
name to which the initial transfer is to be made or a 
deck name, in which case the initial transfer is to the 
standard entry point of that deck. 
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A sentry card is not needed when one of the follow- 
ing conditions exists: 

1. The main program is a Fortran iv program. 

2. The main program is processed first, and the de- 
sired entry point is the standard entry point of that 
program. 

When a sentry card is used, it must immediately 
follow the source deck. The sentry card precedes 
either an end-of-file card or a sdata card. 

$DATA Card 

TVip> strata onrrl ic nn trvt 1401 ntilitv nrncrram onnrrnl 
^.—^ — .._.» — .„ »„ — j j. — 

card. The sdata card indicates the beginning of a data 
file on the input unit. An end-of-file card performs the 
same function and may be used in this capacity. The 
data file must be followed by an end-of-file card. 
The format of the sdata card is: 

1 

$DATA 
$ENDREEL Card 

TTn=k txrxmpFTPT r*arr\ rvancfic ex rppl cwi'Mh "inv^lviTiC frnp 

system input unit (sysini) and the secondary input 
unit ( sysin2 ) . The sendreel card must be preceded by 
an end-of-file card. This card must not appear in the 
middle of a data file. 

The format of the sendreel card is: 

1 

$ENDREEL 
$POST Card 

The spost card causes the Processor Monitor to call 
the Debugging Postprocessor. This card is only used to 
restart a Processor Monitor application ( 1 ) that has 
failed during execution of the object program and ( 2 ) 
in which debugging information has been written on 
sysck2. The on-line message 

DEBUG INFORMATION ON SYSCK2 (unit) 
is printed indicating this condition. 

The format of the spost card is : 

1 

SPOST 

$IBREL Card 

The sibrel card indicates that no more compilations 
or assemblies follow on the system input unit (sysini ). 
The ibjob Processor Monitor then reads the load file 
for the Loader until a file mark is read, at which time 
the input file on the system input unit is read until the 
end of the Processor Monitor application. In effect, 
the stbrel card supplements the source option on the 
sibjob card. A program may have compilations and 
assemblies up to this point, but this card indicates 
that no more will follow. The Loader gains control 
when the sibrel card is recognized. 
The format of the sibrel card is: 

1 

$IBREL 



$TITLE Card 

The stitle card causes the information contained in 
columns 16-72 to be printed as the heading for the 
next Compiler and/or Assembler output (pre- 
empting the normal or installation accounting routine 
heading). 

The format of the stitle card is : 

1 8 16 

$TITLE [NODAT] any text 

If the nodat option is specified, a date is not printed. 
' tuc option is not specincu, u 
Date word ( sysdat ) is printed. 

Input/Output Control Cards 

Input /Output Editor 

The input/output editor, which is a part of the Proc- 
essor Monitor, regulates the input/output operations 
of the ibjob Processor. The input/output editor reads 
from the system input unit (sysini) or from a unit 
specified by the programmer. Both punched output 
( written on the system peripheral punch unit [syspp] ) 
and listing output ( written on the system output unit 
[sysoui]) are prepared by the input/output editor. 
The programmer can specify a temporary alternate 
unit for the system output unit. 

The input/output editor also writes the output from 
both compilers and reads the input for the Assembler 
and the Loader. 

The ibjob Processor uses the following system units: 

1. System input units ( sysini and sysin2 ) 

2. System output units ( sysoui and sysous ) 

3. System peripheral punch units (sysppi and 

SYSPP2 ) 

4. System utility units (sysuti, sysut2, sysut3, and 

SYSUT4) 

Figure 3 illustrates the flow of control and the input/ 
output flow through the ibjob Processor. 

The control cards used to specify input/output con- 
figurations and formats are the siedit and soedit cards. 
When these control cards are used, they must precede 
the component control card of the deck that is affected 
by them. The specifications on the control card remain 
in effect either until the end of the application or until 
another siedit or soedit card changes the specifications. 
The standard specifications are used until one or both 
of these control cards change them. The formats of 
the siedit and soedit cards and explanations of their 
options are given in the following text. 

$IEDIT Card 

The siedit card sets input specifications for the re- 
mainder of the application or until the next siedit card 
is read. 
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System 
Monitor 
(IBSYS) 



SYSOU1/SYSOU2 
List 




SYSIN1/SYSIN2 
or SYSxxx 



SYSUT2 




The flow of control is designated by solid lines, whereas input/output flow is designated by dotted lines. 

Figure 3. Flow of Control and Input/Output Flow Through IBjOB Processor 



The format of the siedit card is: 

1 16 

SIEDIT [, options] 

The options in the variable field are described in the 
following text. 
Input Options 



r j SYSINl ) 1 
L' i SYSxxx \ J 



SYSiNi— The source, symbolic, or object program im- 
mediately follows the component control card on the 

.. / \ 

system mDut unit ' sysini ■. 

sysxxx— The source, symbolic, or object program is on 

the specified alternate input unit. Only those system 

unit names not used by the ibjob Processor may be 

used (SYSCK1, SYSCK2, SYSLB2, SYSLB3, SYSLB4 ) . 

If neither the system input unit nor an alternate 
input unit is specified, the input is read from the 
system input unit ( sysini ) . 

Note: sysck2 is not available as an alternate input 
unit if debugging has been requested. syslb2, syslb3, 
and syslb4 may not be available if used to store system 
components. 

Search Options 

~ ( NOSRCH) "I 
' < SRCHn > 
L VSCHFn / -I 

nosrch— The specified alternate input unit is posi- 
tioned correctly. 

SRCHn— Search through the designated number of files 
(n files) on the specified alternate input unit, for the 
source, symbolic, or object program whose deck name 
is the same as the deck name in the component control 
card. 

scHFn — Search the designated file ^nth file ^ on the 
specified alternate input for the source, symbolic, or 
object program whose deck name is the same as the 
deck name in the component control card. This option 
cannot be used if the alternate input unit is disk storage 
or drum storage. 

The n may be a one- or two-digit decimal number. 
If a comma or a blank immediately follows the srch 
or schf portions of the options, the number is assumed 
to be 1. 

If neither nosrch, SRCHn, nor scHFn is specified, the 
alternate input unit is not searched ( nosrch ) . 

Alter Options 

M NOALTER M 
Li ALTER [J 

noalter— There are no alter cards within the deck. 

alter— There are alter cards in the deck. 

If neither noalter nor alter is specified, it is as- 
sumed that there are no alter cards ( noalter ) . For a 
description of the alter procedure, see "Altering An 
Input Deck." 



$0£D/T Card 

The soedit card sets output specifications for the re- 
mainder of the application or until another soedit card 
is read. 

The format of the $oedit card is : 

1 16 

$OEDIT [, options] 

The options in the variable field are described in the 
following text. 
Output Options 



I \ SYSQU1 / I 
H SYSxxx J J 



sysoui— The output listings for this deck are placed 
on the system output unit. 

sysxxx— The output listings for this deck are placed on 
the specified alternate output unit. Only those function 
names not used by the ibjob Processor may be used 

(SYSCK1, SYSCK2, SYSLB2, SYSLB3, SYSLB4). 

If neither sysoui nor an alternate output unit is speci- 
fied, the output is written on the system output unit 

(SYSOUl). 

Note: sysck2 is not available as an alternate output 
unit if debugging has been requested. syslb2, syslb3, 
and syslb4 may not be available if used to store system 
components. 

Assembler Prest Options 

f j XOPREST ) "I 
L ] PREST (J 



NOPREST— A Pr 



est symbolic uecK is not wanteu. 



prest— A compressed form of the symbolic input to 
the Assembler is written on the system peripheral 
punch unit. The deck produced is called the Prest 
deck. The Fortran Compiler does not produce input 
to the Macro Assembly Program; therefore, a Prest 
deck cannot be obtained for a Fortran compilation. If 
this option is specified for a Fortran compilation, it is 
ignored. 

Programs in Prest format must be submitted in the 
following sequence: 

SJOB 

$EXECUTE $IBJOB 

SIBJOB [options] 

[component control card in BCD format ( $IBMAP, $IBFTC, or 

$IBCBC) appropriate to the IBJOB component that processes 

the deck] 

[deck in Prest format as punched out] 

[end-of-file card] 

SIBSYS 

SSTOP 

In resubmitting decks in Prest format for processing, 
the programmer should reinsert any $-control cards 
used in the original source program, except the scbend 
card. For example, if two decks in a source program are 
separated by a sorigin card, a duplicate sorigin card 
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must be inserted between the corresponding Prest or 
Cprest decks. 

Prest cards consist of series of field counts, string 
counts, and strings, which have been formed by scan- 
ning each field of an input card. A string consists of 
those characters in a field other than the leading blanks. 
Prest cards, generated in column-binary format, do not 
include control cards. 

A field, and therefore a string, may not exceed 67 8 . 
For example, if there are 72 (110 8 ) consecutive char- 
acters but never more than two consecutive blanks, 
the field would be coded as: 



FIELD 


STRING 




FIELD 


STRING 




COUNT 


COUNT 


STRING 


COUNT 


COUNT 


STRING 


67 8 


67g 


XXXXX... 


218 


21s 


XXXXX... 



The characters 77 signify the end of the encoded 
input card. Trailing blanks on the input card are not 
encoded. 

The following examples illustrate Prest output: 

The input card 

1 8 

PRESbbbCLAbbbbbXYZb b 

is encoded as: 

04 04 P R E S 06 03 C L A 10 03 X Y Z 77... 

The input card 

1 8 

bbbbABCbXYZbbDEFbb b 

is encoded as: 

20 14ABCbXYZbbDEF 77 



The following is an illustration of a column binary 
card containing 22 data words. Positions 4-7 distinguish 
a Prest from a Loader or relocatable deck. 



ORD POSITION CONTENTS 


1 S, 1 


1 1 ( examine bit 3 ) 


2 


check-sum control bit 




0= verify check sum 




1 = do not verify check sum 


3 


( standard IBJOB Processor deck ) 


4 


1 \( Prest deck) 


5-7 


111/ 


8-12 


01010 



13-17 word count ( beginning with word 3 ) 
21-35 card sequence number 
2 S, 1-35 logical check sum of word 1 and all data 
words on the card 
3-24 S, 1-35 22 words containing either instructions or 
data from the program. 

The contents of a column-binary card are described 
more fully in the "Loader Input" section of "Loader 
Information." 

If neither noprest nor prest is specified, the Prest 
deck is not generated ( noprest ) . 

Compiler Prest Options 



MNQCPR n 
L j CPREST $ J 



nocpr— A Prest symbolic deck of the source input 
to either the Fortran or the cobol Compiler is not 
wanted. 

cprest— A Prest deck of the source input to either 
compiler is written on the system peripheral punch 
unit. Programs in Compiler Prest format can be sub- 
mitted for processing in the same manner as Prest 
programs (see "Assembler Prest Options"). 

The format of cards which form a Compiler Prest 
deck is the same as for the cards which form an As- 
sembler Prest deck. 

If neither nocpr nor cprest is specified, a Prest deck 
is not generated (nocpr). 

If both prest and cprest are specified in the $oedit 
card that precedes a source deck, both compiler input 
and output are written, in that order, on the system 
peripheral punch unit in. 

Altering an Input Deck 

Any symbolic, source, or Prest input deck can be modi- 
fied. To change an input deck, alter must be specified 
on the siedit card, and Alter control cards must be 
used. These control cards are described later in the 
text. 

If an alternate input unit is not specified on the siedit 
card, it is assumed that the Alter control cards must 
follow a component control card and precede the input 
deck on the system input unit. Before the deck can be 
altered, the Alter control cards are moved to the 
system utility unit (sysut2). When the deck has been 
altered, the system utility unit (sysut2) is repositioned 
to be used for load file output. 

If an alternate input unit is specified on the $iedit 
card, the input deck must be on the alternate input 
unit and the Alter deck must be on the system input 
unit. The input deck must be preceded by a com- 
ponent control card. The Alter deck must also be 
preceded by a component control card of the same 
type and with the same deck name. 

The Alter feature does not produce an updated 
source or symbolic tape. 

Alter Numbers 

The contents of columns 73-80 of an input card are 
used as Alter numbers. An Alter number is generated 
before compilation or assembly when a Prest deck is 
requested as output. This generated number appears 
on the assembly or compilation listing, where columns 
73-80 (identification field) of a card are normally 
printed. The numbers are a maximum of eight right- 
justified sequential digits with leading blanks. 

If a source deck or symbolic deck is to be altered, 
the existing identification fields are used as Alter num- 
bers. They are replaced on the listing with generated 
Alter numbers if a Prest deck is requested as output. 
This is necessary to enable alteration of the Prest deck. 
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Alter Control Cards 

A source, symbolic, or Prest deck may ue altered by 
using the following control cards: 

1. To insert cards into a deck, a control card with 
the following format is used: 

1 8 16 

m *ALTER nl 

Fields m and n are the contents of the identification 
field (columns 73-80) of a control card in the input 
deck, if the deck is a source or symbolic deck. If the 
input deck is a Prest deck, fields m and nl are the 
generated Alter number. The first blank character ap- 
pearing in the identification field indicates that all prior 
characters constitute field m. The characters remaining 
after the blank or blanks constitute field nl. In the 
identification field, field m is left-justified and field 
nl is right-justified. If the identification field contains 
no blank characters, field m may be omitted or may 
consist of no more than the first six characters of the 
identification field. Field nl then consists of the re- 
maining characters that were not placed in field m. 
Fields m and nl must have a total number of char- 
acters equal to the number of characters in the identi- 
fication, excluding leading or embedded blanks. For 
example, if the identification in columns 73-80 is 
label090, the format for this identification, on an Alter 
control card, could be in any of the following forms: 



1 


8 


16 


LABEL 


*ALTER 


090 


LABELO 


*ALTER 


90 


LAB 


*ALTER 


EL090 




*ALTER 


LABEL090 



If the identification in columns 73-80 is LABELbb9, 
the format for this identification is: 
1 8 16 



LABEL 



*ALTER 9 



If there are embedded blanks in the identification, 
the Alter control card must have the preceding format. 
Cards following the Alter control card up to, but not 
including the next Alter control card, are inserted 
immediately before card mn. 

2. To delete and/or insert cards in a deck, a control 
card with the following format is used: 

1 8 1(3 

m *ALTER nl, n2 

Fields m and nl are defined in item 1. Fields m and 
n2 are either the same as m and nl, in which case 
only card mnl is deleted, or they identify a card fol- 
lowing card mnl, in which case cards mnl through 
mn2 are deleted. In addition, any cards following this 
Alter control card, up to but not including the next 
Alter control card, are inserted in place of the deleted 
cards. 



3. To end the Alter deck, a control card with the 
followin° r format is used: 

1 8 

*ENDAL 

This control card denotes the end of the Alter deck 
and must be the last control card in every Alter deck. 

Sample Deck Format Using an Alternate Input Unit 

Figure 4 shows the control cards that are necessary 
for the compilation and/or assembly and simultaneous 
execution of program decks located on both the system 
input unit and an alternate input unit. 



[End of File 



SENTRY DECK3 



I (MAP source deck) 
|$IBMAP DECK4 ~~ 
I SIEDIT SYSIN1 ' 

j$!BFTC DECKS 
|$IBMAP DECK2 



V 



SIEDIT SYSLB4 



(MAP source deck) 



V 



$IBMAP 



l$IBJOB 



SEXECUTE IBJOB 



$JOB 



J 



J 



End of File 



|(FORTRAN sourc e deck)) 
$IBFTC DECK3 



h 



(MAP source deck) 



$IBMAP DECK2 



^ 



J 



SYSIN1 



SYSLB4 



Figure 4. Sample Control Card Deck for Use of an Alternate 
Input Unit 

After the sjob, sexecute, and $ibjob cards have been 
read, the sequence of operations is: 

1. The sibmap card is read from the system input 
unit ( sysini ) , and the map language deck is assembled. 

2. The $iedit card, specifying the system Library 
unit ( syslb4 ) as the alternate input unit, is read. This 
causes all input except the component control card to 
be read from the system Library unit ( syslb4 ) . 

3. The sibmap card, specifying deck2, is read from 
the system input unit ( sysini ) . The data in columns 
1-15 on this sibmap card and on the corresponding 
sibmap card on the system Library unit (syslb4) is 
matched, and the map language deck on syslb4 is as- 
sembled. 

4. The sibftc card, specifying deck3, is read from the 
system input unit (sysiki). The data in columns 1-15 
on this sibftc card and on the corresponding sibftc 
card ( syslb4 ) is matched, and the fobtran iv language 
deck on the syslb4 is compiled and assembled. 

5. The siedit card, specifying the system input unit 
(sysini), is read. This causes the ibjob Processor to 
resume the reading of input from the system input unit 
(sysini ). 
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6. The sibmap card, specifying deck4, is read from 8. The file mark is read on the system input unit 
the system input unit (sysini), and the map language (sysini). Since the nogo specification did not appear 
deck is assembled. in the ibjob card, the reading of the file mark causes 

7. The sentry card, specifying deck3, is read from the loading and execution of all program decks com- 
the system input unit (sysini). This indicates that con- piled and/or assembled by the ibjob Processor during 
trol is to be transferred to the standard entry point of the application. 

deck3 when the object program is loaded. 
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FORTRAN IV Compiler (IBFTC) 



The fortean iv Compiler translates programs written 
in the Fortran iv language, assembles these programs, 
and produces relocatable binary input to the Loader. 

$IBFTC Card 

The Fortran iv Compiler is called into core storage 
when the Processor Monitor reads a sibftc card. The 
sibftc card contains the name of the deck that will fol- 
low, output options (list and punch operations), and 
machine-oriented options that increase the efficiency 
of the object program. 

The format of the sibftc card is: 1 



1 



16 



$IBFTC deckname [, options] 

where deckname names the deck that follows. A deck 
name of six or fewer characters must be punched in 
columns 8-13. Characters that cannot be used in the 
deck name are parentheses, commas, slashes, quotation 
marks, equal signs, and embedded blanks. 

The variable field starts in column 16. The options 
that may appear in this field are described in the fol- 
lowing text. 

List Options 

T f NOLIST > ~l 

><LIST | 

LIfulistv J 

nolist — A listing of the object program is not 
wanted. 

list — A map language listing of the object program, 
three instructions per line, is generated. Only the rela- 
tive locations and symbolic information are listed. See 
Figure 5 for an example of such a listing. 

fulist — A map language listing of the object pro- 
gram is generated, one instruction per line. This listing 
includes generated octal information and resembles 
clie example in if igure o. 

If neither nolist, list, nor fulist is specified, a list- 
ing of the object program is not generated (nolist). 
A listing of the source program, however, is always 
generated. 

BINARY CARD (NOT PUNCHED) 



00032 
00071 
00074 
00032 
00033 
00034 
00040 
00043 



1A 
2A 



3AA 
3AC 



USE .PROL. 
USE .ERAS. 
BSS l.F 
NULL 
NULL 
STZ I 
CLA •« 
FAD «« 



Punch Options 

M DECK n 
£ JNODECKj J 

deck — The object program deck is written on the 
system peripheral punch unit. 

A 1_ - J Jl - _1_ • i i__J 

jv ij iy hxjK — li. pUIICIICU. Qt?CK IS IlOl WHIitGCl. 

If neither deck nor nodeck is specified, the object 
program deck is written on the system peripheral 
punch unit ( deck ) . If Prest and Cprest decks have also 
been requested, the object deck is written last. 

Instruction Set Options 

" ( M90 ) 
'<M94 > 
- VM94/2/ -I 

M90 — The map language program uses only 7090 
machine instructions, map language double-precision 
operations are simulated by system macros, and even 
pseudo-operations are treated as commentary. 

M94 — The map language program uses only 7094 
machine instructions. 

M94/2 — The map language program uses 7094 ma- 
chine instructions, map language even pseudo-opera- 
tions are treated as commentary. 

If neither M90, M94, nor M94/2 is specified, the map 
language program uses only 7090 machine instructions 
(m9o). Fortran programmers should specify M94 if 
the machine they are using is a 7094 and M94/2 if the 
machine thev are using is a 7094. model 2. 



Index Register Options 



[•i 



xrs — The map language program uses three index 
registers (1, 2, and 4). 

xRn — The map language program uses n index 
registers (n is a number from 4 to 7). 

If neither xr3 nor XRn is specified, the map lan- 
guage program uses only three index registers (xr3). 
Fortran programmers should specify the number of 
index registers available on the machine they are using. 



00032 




USE .MAIN 


00073 




USE .STOR 


00032 




USE .MAIN 


00032 


1 AA 


STZ *» 


00033 




AXC 1.1 


00035 


2A1 


FSCA 1,1 


00041 


3AB 


FDP •• 


00044 




FOP *2. 



00071 




USE .TBST 


00073 


I 


BSS l.X 


00032 


29. 


NULL 


00033 


31. 


NULL 


00034 


32. 


NULL 


00040 


3A 


NULL 


00042 




XCA 



Figure 5. Listing of Object Program, Three Instructions per Line 
1- Note that the symbol table option is no longer available. 
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Debugging Dictionary Options 



' ( NODD ) 
<DD 
■ ISDD 



I] 



nodd — A debugging dictionary is not wanted. 

dd — A full debugging dictionary is desired. All sym- 
bols used in the assembled program will appear in the 
debugging dictionary. In the case of a Fortran iv 
program, the debugging dictionary includes all state- 
ment numbers, all programmer-specified symbols, and 
all symbols generated by the Fortran Compiler. 

sdd — A short debugging dictionary is desired. Only 
those symbols will appear in the debugging dictionary 
that are specified through keep pesudo-operations sup- 
plied by the map programmer. In the case of a Fortran 
iv program, the Compiler generates keep operations for 
statement numbers and programmer-specified symbols 
when sdd is chosen. 

If neither nodd, dd, nor sdd is specified, a debugging 
dictionary is not generated ( nodd ) . 



| End of File 



^FORTRAN source de^y^\ 
1 SIBFTC DECK1 ' 



$IBJOB 



SEXECUTE IBJOB 



$JOB 



Figure 6. Sample Control Card Deck for One FORTRAN IV 
Compilation 



Sample FORTRAN IV Deck Format 

Figure 6 shows the control cards necessary for compila- 
tion and execution of one Fortran iv language deck. 

Figure 7 shows the control cards necessary for com- 
pilation and execution of two Fortran iv language 
decks. When execution begins, control is transferred to 
the first instruction in the first deck. Fortran decks 
grouped together as shown permit phasing during 
Fortran iv compilation. (See "fortran rv Compiler 
Information" for a discussion of phasing.) 



1 End of File 



(data file deck) 



$DATA 



(FORTRAN source deck) 



a 



SIBFTC DECK2 



(FORTRAN source deck) 



ti y 



| SIBFTC DECK1 
JSIBJOB 
SEXECUTE IBJOB 



SJOB 



^ 



J 



J 



Figure 7. Sample Control Card Deck for Two FORTRAN IV 
Compilations 



A data file for the object program follows the source 
language decks. The $data card that precedes the data 
file causes a file mark to be written when it is recog- 
nized by the peripheral input/output program. When 
the ibjor Processor reads the file mark, loading and 
execution of the object program begin. 
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COBOL Compiler (IBCBC) 



The cobol Compiler translates programs written in the 
cobol language and produces map language input to 
the Assembler. 

$IBCBC Card 

The cobol Compiler is called into core storage when 
the Processor Monitor reads a sibcbc card. The sibcbc 
card contains the name of the deck that will follow, 
output options (list and punch operations), and ma- 
chine-oriented options that increase the efficiency of 
the object program. 

The format of the sibcbc card is: 

1 8 16 

$IBCBC deckname [, options] 

where deckname names the deck that follows. A 
deck name of six or fewer alphanumeric characters 
must be punched in columns 8-13. At least one char- 
acter must be alphabetic or a period. Characters that 
cannot be used in the deck name are parentheses, com- 
mas, slashes, quotation marks, equal signs, hyphens, 
and embedded blanks. 

The variable field starts in column 16. The options 
that may appear in this field are described in the fol- 
lowing text. 

List Options 

~ f NOLIST ) 
'<LIST > 

LIfulist/ J 

nolist — A listing of the symbolic object program 
input to tiie /^ssemuier is not wanteu. .terror messages 
produced by the Assembler are listed. 

list — A map language listing of the symbolic object 
program input to the Assembler, three instructions per 
line, is generated. Only the relative locations and sym- 
bolic information are listed. The format shown in Fig- 
ure 5 for fortban is used also for cobol. 

fulist — A map language listing of the object pro- 
gram is generated, one instruction per line. This list- 
ing includes generated octal information. An example 
of such a program listing is shown in Figure 8. Read- 



ing from left to right, the first 5 digits show the relative 
location of the instruction within the deck. ( Note that 
the pseudo-operation null has no number, since it 
does not appear in the object program. ) The next 12 
digits are the instruction in octal form. The 5 bits 

£~11~„ T ,-~,v „~^ — 1~^„4-,- U,-4-„ /„„,, "TJ^I „4-„Ul^ T3,*^,«^,r 

jLUiiww.ij.iij aic iciuuauun L/iU> i jcc nciucaLauic uiiiaxv 

Text" in the section "Loader Information"). Next fol- 
lows the instruction in symbolic form, enxxx numbers 
are "equivalent names," i.e., map symbols that the 
cobol Compiler generates for names in the source 
program, gnxxx numbers are supplementary symbols 
needed to translate the program into map language. 
If no option is specified, a listing of the source pro- 
gram is generated, but not of the program output to the 

aaciiiuici i rN wi_iib j. j . 

Symbol Table Options 

EiiW] 

noref — A sorted dictionary and a cross-reference 
table are not wanted. 

ref — A sorted dictionary of the source language 
names and their associated equivalent name (enxxx) 
numbers and a cross-reference table of the symbols 
used in the object program are generated. The follow- 
ing is an example of a cross-reference dictionary: 



SOURCE PROGRAM NAME 

FIELD1 

FIELD2 

OUTPUT-FILE 

OUTPUT-RECORD 

WORK-RECORD 



EQUIVALENT NAME NUMBER 

EN0255 
EN0257 
EN0244. 0250 
EN0251 
EN0254 



If neither noref nor ref is specified, the dictionary 
and table are not generated ( noref ) . 
Punch Options 

M DECK M 

[_ jnodeckj J 

deck — The object program input to the Loader is 
written on the system peripheral punch unit ( sysppi ) . 
nodeck — A punched deck is not wanted. 





00070 




EN0251 


NULL 








C0C7O 


0074 00 4 00232 


10001 


EN0252 


TSX 


GN0012 


4 




00071 


0441 00 f; 00210 


10001 




LDI 


SP + 5 






C0072 


0604 00 02C00 


10011 




STI 


.CAREF 






00073 


0441 00 C 00142 


10001 




LDI 


PI + 1 




EN0244 


C0C74 


0604 00 (; 02400 


10011 




STI 


.CBREF 






C0075 


0074 00 4 03000 


10011 




TSX 


.CMPK3 


4 




[NARY CAKD (NOT PUNCHED) 














00C76 


1 00006 1 06C00 


10011 




TXI 


.CANA1 


lf6 




00C77 


0074 00 4 00232 


10001 




TSX 


GN0012 


4 





Figure 8. Object Program Instructions Generated One Instruction per Line from a COBOL 
Program 
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If neither deck nor nodeck is specified, the object 
program is written on the system peripheral punch unit 
( deck ) . 

Instruction Set Options 

"(M90 )■ 

><M94 > 

L IM94/2/ - 

M90 — The map language program uses only 7090 
machine instructions, map language double-precision 
operations are simulated by system macros, and even 
pseudo-operations are treated as commentary. 

M94 — The map language program uses only 7094 
machine instructions. 

M94/2 — The map language program uses 7094 ma- 
chine instructions, map language even pseudo-opera- 
tions are treated as commentary. 

At present, only the M90 option is used by the Com- 
piler, regardless of the specification made. 

Index Register Options 

HXR3M 
hxR7U 

XR3 — The map language program uses three index 
registers (1, 2, and 4). 

XR7 — The map language program uses seven index 
registers. 

If neither XR3 nor xrt is specified, the map language 
program uses only three index registers (xr3). corol 
programmers should specify the number of index regis- 
ters available on the machine they are using. 

Code Options 

f j INLINE 1 1 
LJ TIGHT }J 

inline — The object program's computational and 
move tasks are optimized for speed. 

tight — The object program's computational and 
move generated coding is shorter, thereby conserving 
object-time core storage. 

If neither inline nor tight is specified, the object 
program's computational and move tasks are optimized 
for speed (inline). 

Tape Error Options 

r upend n 
L'{ readon} J 

ioend — Errors in reading tape at object time cause 
irrecoverable error conditions. 

readon — Errors in reading tape at object time are 
ignored. This option may be used to allow high-volume 



data processing to continue while ignoring low-volume 
error conditions. 

If neither ioend nor readon is specified, these errors 
cause irrecoverable error conditions (ioend). 

Collating Sequence Options 

f { COMSEQ ? "I 

L'Jbinseq (J 

comseq — The object program uses the commercial 
collating sequence. 

rinseq — The object program uses the binary scien- 
tific collating sequence. 

If neither comseq nor rinseq is specified, the object 
program uses the commercial collating sequence 
( comseq ) . 

Debugging Dictionary Options 

r\ NODD M 
L'JDD- U 

nodd — A debugging dictionary is not wanted. 

dd — A debugging dictionary is desired. A debugging 
dictionary helps in debugging a map program gener- 
ated by the corol Compiler. The corol Compiler takes 
no action on this option except to pass it to the Assem- 
bler. The Assembler then produces a dictionary con- 

toinit-irr oil rarer an^ re\f4P off>np>rntAn cvmnnK 

If neither nodd nor dd is specified, a debugging dic- 
tionary is not produced ( nodd ) . 

$CBEND Card 

Every cobol source deck must be followed immediately 
by a scbend card. 

The format of the scbend card is: 

1 

$CBEND 

Debugging for COBOL Programs 

The cobol Compiler can also provide debugging aids 
during compilation of cobol decks. This optional fa- 
cility is described under "Compile-Time Debugging." 

Sample COBOL Deck Format 

Figure 9 shows the control cards necessary for compila- 
tion and execution of a single cobol language deck. 

Figure 10 shows the control cards necessary for 
compilation and execution of two cobol language 
decks. When execution begins, control is transferred to 
the standard entry point of the first deck. 

Note: Any number of cobol source decks or map or 
Fortran source decks may appear between the sibjob 
and end-of-file cards. 
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I End of File 



$CBEND 



j (COBOL sou 
j SIBCBC DECK1 
| $IBJOB \ 


rce d 

\ 


sck)\ 


|$EXECUTE IBJOB 


\ 






$JOB \ 







1 End of File 
1$CBEND 

I (COBOL source deck)\/ 



SIBCBC DECK2 



SCBEND 



i 



(COBOL source deck) 
$IBCBC DECK! 



& J 



SlBJOB 



SEXECUTE IBJOB 



$JOB 



Figure 9. Sample Control Card Deck for One COBOL Com- 
pilation 



Figure 10. Sample Control Card Deck for Two COBOL Com- 
pilations Which Compile As a Single Job 
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Macro Assembly Program (IBMAP) 



The Macro Assembly Program (the Assembler) proc- 
esses programs written in the map language as well as 
generated map programs that are output from the 
cobol Compiler. The output from the Assembler can 
be either in relocatable binary form or in absolute 
binary form. The relocatable binary output is proc- 
essed, if required, by the Loader. The Loader is used 
for processing and loading when either go, logic, 
dlogic, or map is specified in the sibjob card. An ex- 
planation of these options can be found in the section 
"sibjob Card." The object program, which is a result of 
assembling and loading, is composed of machine in- 
structions that are generated by the Assembler, the 
input/output routines that are part of the Subroutine 
Library, and possibly the Fortran iv mathematical 
subroutines from the Subroutine Library. The use of the 
mathematical subroutines by the map programmer is 
described in the section "Subroutine Library (iblib)." 

$IBMAP Card 

The Assembler is called into core storage when the 
Processor Monitor reads a sibmap card. The sibmap 
card contains the name of the deck that follows, the 
type of assembly to be performed, output operations 
(list and punch options), and restrictions on the use 
of the map language in the deck that follows. 

The format of the sibmap card is: 
1 8 16 



$IBMAP 


deckname [, options] 




BINARY CARD 1 


[NCT PUNCHED) 






00000 


0774 00 1 00011 


10000 


START AXT 


00001 


0500 00 1 00025 


10001 


CLA 


00002 


0400 00 1 00026 


10001 


LOCP ADD 


00003 


2 000C1 1 00002 


10001 


TIX 


00004 


0601 00 00025 


10001 


STO 


00005 


OOOOOOOOOCOO 


00010 


CALL 


00005 


0074 00 4 02000 


10011 




00006 


1 00003 01005 


10011 




00007 


00026 00006 


10100 




00010 


00000 00013 


10001 




00011 


00000 00026 


10001 




00012 


00000 00002 


10000 




00013 


00000C000C01 


10000 


NUMBER DEC 


00014 


O0O00OOOCCO2 


10000 




00015 


000000000003 


10000 




00016 


O0OOOC000CO4 


10000 




00017 


OC0000000005 


10000 




00020 


000OOOCO0CO6 


10000 




00021 


O0OO0OOOOCC7 


1000C 




BINARY CARD (NOT PUNCHED) 






00022 


000C00000C10 


10000 




00023 


OOOOOOOOOCll 


10000 




00024 


OCOC00000012 


10000 




00025 


200000000COI 


00001 


SUM BSS 


00026 


OCOOOOOOOOOC 


10000 


•LOIR 


00027 


235163212260 


10000 






00000 


01111 


END 



where deckname identifies the deck that follows. A 
deck name of six or fewer alphameric characters must 
be punched in card columns 8-13. Characters that can- 
not be used in the deck name are parentheses, commas, 
slashes, quotation marks, equal signs, and embedded 
blanks. 

The options in the variable field, which starts in col- 
umn 16, are described in the following text. 

Card Count Option 

[, count] 

The card count option is an estimate of the number 
of symbolic language cards in the deck. The number 
may not exceed 32,767. If a card count is not speci- 
fied, a count of 2,000 is assumed. 

List Options 
T (LIST ) 



U NOLIST } J 



list — A listing of the object program is generated. 
nolist— A listing of the object program is not wanted. 
If neither list nor nolist is specified, a listing of the 
object program is generated (list). 
Symbol Table Options 

r.iSEFM 

Unorefu 

ref — A cross-reference table of the symbols used in 
the object program deck is generated. The deck listed 
in Figure 11 would result in the cross-reference table 
shown in Figure 12. In this table, under "Class," each 



9, 1 

NUMBER+10,1 

NUMBER+11,1 

LOOP, 1,1 

SUM 

DUMP(NUMBER,SUM+1,2) 



1,2,3,4,5,6,7,8,9,10 



START 



Figure 11. Program That Would Result in Cross-Reference Table Shown in Figure 12 
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CRTAB 
SYMBOL REFERENCE DATA 



REFERENCES TO DEFINED SYMBOLS- 
CLASS SYMBOL VALUE REFERENCES 

LOOP 00002 3 
NUMBER 00013 It 2, 10 

LCTR BLCTR 

QUAL UNQS 

LCTR // 

START 00000 30 
SUM 00025 4,11 

REFERENCES TO VIRTUAL SYMBOLS. 
DUMP 2 5 



Figure 12. Cross-Reference Table Resulting from Program 
Listed in Figure 11 



symbol is classified by the types of defined symbols: 
ordinary symbols, location counter symbols, qualifying 
symbols, file names and symbols defined by bool, 
lbool, rbool, or set pseudo-operations. Under "Sym- 
bol" each symbolic name defined in the program is 
listed, "blctr" (blank location counter) and "//" 
( blank common ) are location counter symbols supplied 
by the Assembler. "uNTQs"is a qualifying symbol supplied 
by the Assembler. Under "Value" is shown the relative 
location assigned to each defined symbol within the 
deck. Under "References" are listed the relative loca- 
tions at which the symbols are referred to. "References 
to Virtual Symbols" are the same as for defined symbols, 
except that "Value" is the number of the entry that the 
name occupies in the control dictionary for this deck 
after the preface entry. 

noref — A cross-reference table is not wanted. 

If neither ref nor noref is specified, a cross-reference 
table is generated (ref). 

Punch Options 



rj DECK n 
[_'} NODECK \J 



L'| NODECK^ 

deck — The object program deck is written on the 
system peripheral punch unit. 

nodeck — A punched deck is not wanted. 

If neither deck nor nodeck is specified, the object 
program deck is written on the system peripheral 
punch unit (deck). 

System Symbol Options 

r f N .Q SYM n 

»< MONSYM > 
'-IjOBSYM J- 1 

nosym — No symbols are predefined by the Assem- 
bler. 

monsym — The ibsys Operating System symbols in 
the nucleus and Input/Output Executor (ioex) com- 
munication regions and in the system unit function 
table, and the symbols sysorg and sysend, are prede- 
fined by the Assembler. These symbols are defined as 



being in the qualification section "s.s" and, therefore, 
may be redefined at any point in the program. They 
are described in the publication IBM 7090/7094 IBSYS 
Operating System: System Monitor (IBSYS), Form 
C28-6248. 

jobsym — This option is effective only in an absolute 
mode assembly (absmod). If it appears on a sibmap 
card that does not also specify absmod, monsym is 
assumed. The ibsys Operating System symbols, plus 
the ibjob Processor system symbols used for subcom- 
ponent communication (see Appendix C), are prede- 
fined by the Assembler, as described for monsym. 

If neither nosysm, monsym, nor jobsym is specified, 
all symbols referred to in an absmod assembly must 
be defined by the source program ( nosym ) . 

Instructions Set Options 

( M90 )-] 
<M94 } 
L IM94/2/ J 

M90 — The Assembler generates only 7090 machine 
instructions. Double-precision operations are simulated, 
and even pseudo-operations are treated as commentary. 

M94 — The Assembler generates only 7094 machine 
instructions. 

M94/2 — The Assembler generates only 7094 machine 
instructions, and even pseudo-operations are treated as 
commentary. 

If neither M90, M94, nor M94/2 is specified, the object 
program uses only 7090 machine instructions ( M90 ) . 

Assembly Mode Options 

~ ( RELMOD ) "I 

»< SYSMOD > 

L UBSMOD / J 

relmod — The object program is assembled in re- 

Inootomo r»inar\7 rrvrm 
V 



sysmod — The object program, which has an absolute 
origin, is assembled in relocatable binary form. 

absmod — The object program is assembled in abso- 
lute binary form. 

If neither relmod, sysmod, nor absmod is specified, 
the program is assembled in relocatable binary form 
( relmod ) . 

Parentheses Options 

[«] 

no( )— Parentheses should not be used in map sym- 
bols. If parentheses are used in a symbol in the location 
field, a warning message is printed, but assembly is 
permitted. 

( )ok — Parentheses may be used in map symbols. 

If neither no( ) nor ( )ok is specified, parentheses 
should not be used in map symbols [no( ) ] . 

Built-in Function Options 

|~ j NOMFTC ) 1 
LIMFTC (J 
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nomftc — The built-in functions of the Fortran iv 
Compiler are not used by the object program. 

mftc — The built-in functions of the Fortran iv 
Compiler are used by the object program. These func- 
tions are described in the publication IBM 7090/7094 
IBSYS Operating System: FORTRAN IV Language, 
Form C28-6390. 

If neither nomftc nor mftc is specified, the object 
program does not use the built-in functions ( nomftc ) . 

Debugging Dictionary Options 
~ ( NODD ) ' 

') DD r 

L (.SDD / -I 

nodd — A debugging dictionary is not wanted. 

dd — A full debugging dictionary is desired. All sym- 
bols used in the assembled program are included. 

sdd — A short debugging dictionary is desired. Only 
those symbols that are specified by the map pseudo- 
operation keep appear in the debugging dictionary. 

If neither nodd, dd, nor sdd is specified, a debugging 
dictionary is not produced ( nodd ) . 

Sample MAP Deck Format 

Figure 13 shows the control cards necessary for the 
assembly and execution of a map language deck. 

Figure 14 shows the control cards necessary for the 
assembly and execution of two map language decks. 



When execution begins, control is transferred to the 
standard entry point of the first deck. 



6 



| End of File 



(MAP source deck) 



$1BMAP DECK1 



$IBJOB 



$EXECUTE IBJOB 



$JOB 



Figure 13. Sample Control Card Deck for One MAP Assembly 



1 End of File 



(MAP source deck) 



<\ 



$IBMAP DECK2 



(MAP source deck) 



^ 



$IBMAP DECK1 



$IBJOB 



$EXECUTE IBJOB 



$JOB 



Figure 14. Sample Control Card Deck for Two MAP Assemblies 
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Debugging Package 



The Debugging Package enables the programmer to 
manipulate data, control processing, and obtain dumps 
of the contents of any locations in core storage at speci- 
fied locations within his program. There is no limit on 
the number of requests that may be given for a single 

-»-.i ii. .- ini/ '7r\nr\ inf\C\A 7T50"vG /~\~***m 

program, ine puoncation ldlvl /uw/ tutt ldo±j ^ Rel- 
ating System, IBJOB Processor Debugging Package, 
Form C28-6393, describes the procedure for coding de- 
bug requests. 

This package provides the programmer with two 
types of debugging: compile-time debugging and load- 
time debugging. 

Compile-Time Debugging 

Compile-time debugging may be used with the cobol 
Compiler at compilation to specify dumps at various 
points in a cobol source program. Debug requests are 
similar to cobol procedural statements and almost all 
procedural capabilities of the compiler may be used. 

$/BDBC Card 

The sibdbc card heads each compile-time debug re- 
quest. The sibdbc card serves two functions: it identi- 
fies individual requests, and it defines the point at 
which the request is to be executed. 
The format of the sibdbc card is: 



8 



16 



$IBDBG 



[name] location [, FATAL] 



where name is an optional user-assignea control sec- 
tion name which permits deletion of the request at load 
time. This name must be a unique control section 
name consisting of up to six alphabetic and numeric 
characters, at least one of which must be alphabetic. 

Location is the cobol section-name or paragraph- 
name (qualified, if necessary) indicating the point in 
the program at which the request is to be executed. 
In effect, debug requests are performed as if they 
were physically placed in the source program following 
the section- or paragraph-name, but preceding the text 
associated with the name. Two sibdbc cards in the same 
request packet may not refer to the same location. 

fatal, when specified, prevents loading and execu- 
tion of the object program when an error of a level 
corresponding to the cobol error level E or greater 
occurs within a debug request statement. If fatal is 
not specified, a cobol error of level E or less, when en- 
countered within the procedural text of a debug re- 
quest, does not prevent loading and execution of the 
object program. In this situation an attempt is made 



to interpret the statement. If the interpretation at- 
tempt is unsuccessful, the invalid statement is disre- 
garded. If the request consists of more than one state- 
ment, only the invalid statement is disregarded. 

The text of the debug request follows immediately 

«.. .i 1 ml . . • . _r 1_'J 
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procedural statements conforming to the requirements 
of the cobol language and format and the count-con- 
ditional statement. The only restriction on these state- 
ments is that they may not transfer control outside of 
the debug request itself. Display statements in a debug 
request are written on sysoui. 

An end-of-file card or any $-control card terminates 
the compile-time debugging packet. 



Load-Time Debugging 

The load-time debugging facility allows Fortran iv 
map programmers to insert debug requests at load 
time that are to be executed with the object program. 
The language for load-time debug requests is derived 
from the Fortran iv language, with changes made for 
debugging purposes. All load-time requests for a par- 
ticular Processor application are grouped together in 
what is called the debugging packet. The load-time 
debugging packet is placed immediately following the 
sibjob card at the beginning of the job deck, preceding 
the source and/or object decks. 

$IBDBL Card 

The sibdbl card heads all load-time debugging packets 
and provides options governing the amount of debug- 
ging output. 

The format of the sibdbl card is: 

1 16 

$IBDBL [, options] 

The variable field starts in column 16. Columns 16-72 
are scanned in full and therefore may contain blanks 
for legibility purposes. The options that may appear in 
this field are described in the following text. 

Debugging Output Options 
[, TRAP MAX = ni] [, LINE MAX = n 2 ] 

trap max = n : - All debugging action ceases after 
ni requests have been executed. The symbol n x is an 
integer. In octal, the number of requests may range 
from 01 to 077777. (Any integer containing a leading 
zero is recognized as an octal number. ) If the number 
of requests is expressed in decimal, the range is from 
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1 to 32,767. Each time program execution is halted for 
debugging action, irrespective of any resultant action, 
an executed request is counted. If no trap max is 
specified, the debugging routines allow a maximum of 
30,000 traps. 

line max = n 2 — All dumping ceases after approxi- 
mately n 2 print lines of debugging output have been 
written on tape; the postprocessor prints no more than 
n 2 lines. The symbol n 2 is an integer. In octal, the num- 
ber of lines may range from 01 to 077777. (Any integer 
containing a leading zero is recognized as an octal 
number. ) If the number of print lines is expressed in 
decimal, the range is from 1 to 32,767. If no line max 
is specified, the debugging routines allow a maximum 
of 1,000 lines. 

The number of lines produced by a postmortem 
dump taken at the completion of execution is not in- 
cluded in the line count. To avoid the possibility of 
unlimited dumping during an uncontrolled loop, an 
approximation based upon line max is used to limit 
the number of words written on sysck2 during execu- 
tion. This feature does not limit or prevent the uncon- 
trolled loop. 

Either or both of these options, in any order, may 

be used to control the amount nf Hehiicraincr nnfnnf 

__ 00 — — WJt 

Message Listing Option 
[, NOMES] 



When specified, the nomes option eliminates the 
object-time messages. Debugging output is unchanged, 
except that a preliminary list of the dumps and any 
trap max and line max messages are eliminated. 

*DEND Card 

The *dend card is the last card in the load-time de- 
bugging packet. 

The format of the *dend card is: 

1_ 

*DEND ~" 

Postprocessor Routines 

The Postprocessor routines of the Load-Time Debug- 
ging Processor control the format of debugging output. 
This occurs following execution of the object program. 
If a Processor Monitor application fails during exe- 
cution, the operator must initiate a restart using the 
spost card. See the publication IBM 7090/7094 IBSYS 
Operating System: Operators Guide, Form C28-6355, 
for descriptions of the spost card and the restart pro- 
cedure. 

Sample Load-Time Debugging Deck Format 



Processor Monitor application that uses compile-time 
and load-time debugging. 
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Load-Time 
Debugging 
Packet for 
$IBLDR and 
$IBMAP 
Deck 



Compile-Time 
Debugging Packet 
for $IBCBC Deck 




Figure 15. Sample Control Card Deck for Debugging 
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Relocatable Binary Decks 

A deck produced by the Assembler or the Fortran iv 
Compiler for the Loader is in relocatable binary for- 
mat. Such a deck, called an object deck, is written on 
input/output unit sysppi to be punched out when the 
deck option is specified on the control card for the 
component assembling the deck (sibftc, sibcbc, or 
sibmap card). The sibjob card for the program within 
which the deck appears will also be punched out in 
bcd format. 

The programmer can save compile and assembly 
time by using previously assembled object decks as 
part or all of a program that must be resubmitted for 
processing. In a case where the entire program is com- 
posed of object decks, the programmer can add control 
cards to the decks as follows and resubmit them for 
loading and execution: 

$JOB 

$EXECUTE IBJOB 

[$IBJOB card and decks as punched out] 

[end-of-file card] 

$STOP 

Note: When an object deck follows another deck 
in a program, the sibjob card punched out with the 
object deck should be deleted. 

However, in resubmitting binary decks, the pro- 
grammer must supply again any spool, sgroup, slabel, 

SENTRY, SSIZE, SUSE, SOMIT, SNAME, SORIGIN, Or SINCLUDE 

cards he used in the original source deck. The sorigin 
and sinclude cards must precede the decks to which 
they apply. In the following example the sjob, sexe- 
cute, sorigin, sinclude, ssize, end-of-file, and sstop 
cards were inserted by the programmer: 

1 16 

$JOB 

$EXECUTE IBJOB 

[$IBJOB card and relocatable binary deck #1 as punched out] 

$ORIGIN A 

$INCLUDE SIN [Subroutine from Subroutine 

Library] 
[relocatable binary deck #2 as punched out with $IBJOB card 
deleted] 

$ORIGIN A 

[relocatable binary deck #3 as punched out with $IBJOB card 
deleted] 

$SIZE //=500 

end-of-file card 

$STOP 

An object deck of load-time debugging reference 
tables cannot be obtained. For this reason, even when 
a job is submitted as an assembled object deck, any 
associated load-time debugging requests must be made 
as a source deck, and time for compiling the request 
packet must be expected. 



Note: If the original source program did not request 
a debugging dictionary, the object decks punched out 
from the program cannot be used later with a load- 
time debugging request deck. 

Column Binary Format 

Column binary format is punched on a standard ibm 
card, 80 columns by 12 rows. Columns 73-80 are used 
for bcd identification only; they are not used by the 
Loader. 

The remaining 72 columns are actually 24 sets of 
3 columns each. Since each set of 3 columns has 12 
rows, the set has 36 punch positions, corresponding to 
the 36 possible bits in a machine word. 

The bits are read downward, starting with the first 
column to the left in a word. If the programmer divides 
the 12 rows in each column into groups of 3 bits each, 
he can read 4 octal numbers per column. The top 
bit in each group represents a 4, the middle bit a 2, and 
the last a 1. 

For example, in Figure 16 column 19 reading down- 
ward shows 0-5-0-0 octal; column 20, 0-0-1-0; and 
column 21, 4-0-1-2. Put together to represent the con- 
tents of one word, the numbers are: 



5 

operation 
code 




unused 



tag 



4 12 



address 



or 



CLA 04012,1 



The programmer will find it easier to read column 
binary when the cards are punched on an IBM 704 
Column Binary Card, Form 121-N-2. 




Figure 16. Binary Word Punched in Column Binary Format 
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The Loader processes relocatable binary program decks 
produced by the Assembler or the Fortran Compiler 
and combines any required subroutines from the Sub- 
routine Library with the program decks. The program 
decks produced by the Assembler contain control in- 
formation as well as the relocatable binary text of the 
program. This control information is of two types: 
information describing the file(s) to be used by the 
object program, and information that enables the 
Loader to resolve cross-referencing between sections of 
the program. 

In addition to assigning absolute core storage loca- 
tions to the relocatable binary text of the program and 
resolving cross-references, the Loader also allocates 
core storage for pools of input/output buffers and 
attaches files to the buffer pools. This is done auto- 
matically by the Loader, but a programmer can modify 
this procedure by using control cards. 

The Loader processes one or more relocatable binary 
program decks, prepares one executable object pro- 
gram from these decks, and transfers control to the 
object program. In a tape-oriented system, a program 
deck consists of a series of card images on tape. Any 
number of program decks can be run at one time. All 
of these decks can constitute a Processor application 
when they are grouped together. A Processor applica- 
tion can apply to one program deck or many, some of 
which may operate similarly to closed subroutines or 
subprograms. 

A program deck may contain external names that 
refer to areas of coding or data within other program 
decks. These areas, called control sections, are acces- 
sible to other programs. The Loader recognizes that 
control sections are equivalent to one another by their 
identical names. Only one of each named reference 
item is included by the Loader, which adjusts all cross- 
referencing to the retained item. Therefore, the pro- 
grammer may refer symbolically in one program to the 
name of a control section in another program, and the 
Loader performs the desired cross-referencing. External 
names may be designated using the map pseudo- 
operations contrl, entry, and save; they may be re- 
named, replaced, or deleted at load time, using Loader 
control cards. 

Object Program Files 

Input to the Loader that defines object program files 
comes from two sources: sfile control cards and file 



dictionaries. These are normally produced by the As- 
sembler in processing the file pseudo-operation. The 
Loader constructs file blocks from this information for 
the object program to use during execution. 

The map language programmer uses file pseudo- 
operations for his file descriptions, whereas the Fortran 
user relies on the file routines that establish the rela- 
tion between Fortran logical units and system units. 
The cobol user describes a file by making a file descrip- 
tion entry in the Data Division, and assigns units in the 
File-Control Paragraph of the Environment Division. 

The file specifications generated by the Assembler on 
the sfile card are described in the section "sfile Card." 

If a map language program contains file pseudo- 
operations but makes no reference to an iocs Library 
subroutine such as .open, iocs is not loaded, and no 
buffer pools are attached to the files. 

Loader Name Conventions 

The use of alphameric literals as external identifiers of 
object program quantities is basic to the design and 
mechanization of the Loader. Three types of names 
are used in the Loader: 

1. Deck names, which identify decks and may be 
used to identify or qualify control section names within 
a deck. 

2. Control section names, which identify data and 
procedure sections within the program. When using 
Loader control cards, named sections in one deck may 
be replaced by a section with the same name in another 
deck. These sections may also be renamed or deleted 
from the program. 

3. File names, which identify files within the pro- 
gram. 

Deck Name Rules 

The use of deck names and the rules for forming deck 
names are: 

1. A deck name is composed of six or fewer alpha- 
meric characters, excluding parentheses, commas, 
slashes, quotation marks, equal signs, and embedded 
blanks. 

2. In producing the binary deck, the Assembler 
places the contents of the deckname field of the Com- 
piler and Assembler cards (sibmap, sibcbc, and sibftc) 
in the deckname field ( columns 8-13 ) of the bcd cards 
that delimit the major sections of a program deck. The 
names of the bcd cards are sibldr, sfdict, stext, scdict, 
sddict, and sdkend. 
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3. The deck name may be punched in columns 8-13 
of any other Loader control card, but it is ignored by 
the Loader. 

4. The deck name defines a control section that en- 
compasses the entire deck; therefore, the entire deck 
is a control section. 

5. The deck name may be punched in the variable 
field of the sname, suse, and somit cards to qualify a 
control section name. Action taken on the named con- 
trol section is thus restricted to the deck named. 

6. The deck names of routines in the Subroutine 
Library may not be used as control section name 
qualifiers. 

7. A deck name may not be changed by a sname 
card. However, the control section with that name may 
be renamed by a sname card. 

Control Section Rules 

The use of control sections and the rules for forming 
control section names are: 

1. A control section name is composed of six or fewer 
alphameric characters. Alphameric characters that can- 
not be used in the control section name are parentheses, 
commas, slashes, quotation marks, equal signs, and 
blanks. A control section name is always left-justified 
before processing or comparison, and unused trailing 
positions are filled with blanks. 

2. A control section is a bounded section of coding; 
its length is the difference between the relative location 
of the first word within it and the relative location of 
the last word within it plus 1. 

3. A real control section is any control section re- 
ferred to in a deck that has a relative location assigned 
within that deck. 

4. A virtual control section is any control section 
referred to in a deck that has no known origin or length 
in that deck. A virtual control section must be supple- 
mented by a real control section with the same external 
reference name in either another input deck or in a 
deck in the Subroutine Library. If a virtual control 
section is not supplemented by a real control section, 
an error message is written on the system output unit. 

5. Normally, if the six-character external reference 
names of two or more control sections are identical, the 
Loader retains the first control section encountered 
and deletes the control sections with duplicate names. 

6. In the absence of explicit inclusion through $use 
cards, the first real section with a given name that is 
physically encountered while loading is retained, and 
all succeeding occurrences of it are deleted All refer- 
ences to the given name are adjusted to refer to the 
storage assigned to the retained section, including any 
org pseudo-operations that may have referred to the 
deleted section. 



7. Explicit inclusion of two control sections with 
the same name ( by using deck name qualifications on 
a $use card ) results in a multiple definition of that sec- 
tion. Consequently, an error message is written on the 
system output unit. 

8. Each control section that is referred to by text 
must be defined ( assigned an absolute location by the 
Loader) or execution will not be allowed. For ex- 
ample, if a reference is made to a section mentioned 
on a somit card and no other section with the same 
name is encountered, an error message is written on 
the system output unit. 

9. Control sections can be nested (i.e., control sec- 
tions can be placed within the boundaries of other con- 
trol sections), but each inner nest must be entirely 
within the next outer level of nesting. If an outer level 
of nesting is deleted, all control sections within the 
boundaries of this nest are deleted. If an inner level 
of nesting is deleted or inserted, any references to loca- 
tions between the end of the inner section and the 
end of the outer section are not adjusted. In Figure 
16A, for example, if control section A is deleted from 
within control section B, all references to the locations 
in area C will be incorrect. They will, in fact, refer in 
the final absolute program to instructions in control 
section D. This problem does not arise with an even 
control section which coincides with the beginning of 
another control section, since the even is not treated 
as a nested control section in this case. 
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Figure 16A. Nested Control Sections Where Inner Level is 
Deleted 
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10. Explicit inclusion of a control section through 
specification of a $use card does not necessarily force 
the inclusion of all embedded control sections. 

11. A subroutine in the Subroutine Library is called 
automatically if a control section name in a Library 
subroutine is identical to that of a virtual control 
section and no real control section with that name is 
contained in any input program deck. 

12. Control sections of routines in the Subroutine 
Library may not be renamed. 

13. A control section name specified by an entry, 
contrl, or save pseudo-operation should not be the 
same as the name of the deck that contains it. 

14. If an even appears within a control section, it 



must be at the same relative location as the beginning 
of the control section. 

15. Text that is placed in a control section by means 
of an org pseudo-operation (as in the case of data 
entered in a common block by a Fortran rv block data 
subprogram ) is never deleted. Instead, it is loaded into 
the retained control section. ( See rule 6 above. ) 

File Name Rules 

The following list defines the rules for the formation 
and usage of file names: 

1. A file name is composed of up to 18 alphameric 
characters, excluding parentheses and quotation marks. 

2. Whenever a file name appears on a Loader con- 
trol card, it must be enclosed in quotation marks (4-8 
punch). If the file name is qualified by a deck name, 
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the entire expression is enclosed in quotation marks 
and the file name is enclosed in parentheses. 

3. A file may be renamed through specification on a 
sname card. If the new name that the programmer 
species on the sname card does not already exist, the 
programmer must insert a sfile card containing this 
name. 

4. File names cannot be specified on suse or somit 
cards. 

5. If a file is renamed, any control card that refers 
to the old name is ignored. 

6. If the 18-character names of two or more files are 
identical within a program, the Loader retains the in- 
formation contained in the first sfile card encountered 
and ignores any subsequent sfile cards with the same 
file name. 

Component Control Card for the Loader 

The following card instructs the IBJOB Monitor that 
only the Loader is needed to process the deck headed 
by the card. 

$IBLDR Card 

The first card in a relocatable binary deck is the sibldr 
card in bcd format. The sibldr card is generated by the 
Assembler. 

The format of the sibldr card is: 

1 8 16 

$IBLDR deckname [, options] 

where deckname identifies the deck to be processed. 
The deck name must be six or fewer alphameric char- 
acters. Characters that cannot be used in the deck name 
are parentheses, commas, slashes, quotation marks, 
equal signs, and embedded blanks. 

The variable field begins in column 16. The options 
of the variable field are described in the following text. 
These variable field options can be changed by the 
programmer. 

Input Options 

M NOLIBE M 
HLIBE U 

nolibe— The object program is in the current input 
file. 

libe— The object program is in the Subroutine 
Library. 

When libe is specified, the application must consist 
entirely of object programs from the Subroutine 
Library, libe and nolibe specifications cannot be used 
within the same application. If neither libe nor nolibe 
is specified, it is assumed that the object program is 
in the current input file ( nolibe ) . 

Text Options 

M TEXT M 
nNOTEXTJJ 

text— When this option is specified, the Loader loads 

the text section of the deck that follows. 



notext— The sections of the deck that contain control 
information are loaded, but the text section is not 
loaded. 

If neither text nor notext is specified, the Loader 
loads the text section of the deck that follows ( text ) . 

Loader Control Cards 

This section provides the format specifications for the 
control cards that the Loader processes. These control 
cards describe file and program loading modifications 
lur an tjiiLirt? od^ci ^ro^ram ano tnerexore are not re- 
quired for most Processor applications. The Loader 
control cards may be used to: 

1. Override file or label descriptions that appear in 
the object program. 

2. Modify the control section retention scheme used 
by the Loader. ( In the control section retention scheme, 
the Loader uses the first control section that it en- 
counters with a given name.) 

3. Depart from the standard buffer assignment. The 
section "Input/Output Buffer Allocation" contains 
further information. 

4. Modify control section names or file names. 

5. Delete control sections. 

$FILE Card 

The Assembler normally generates a sfile card in proc- 
essing a file pseudo-operation. But, since the Loader 
retains the first sfile card it reads for any given file as 
its proper definition, the programmer may override 
certain options in an Assembler-generated sfile card by 
placing a sfile card of his own at the beginning of the 
deck involved. These rules, however, must be followed: 

1. Any file specifications that are not changed must 
be repeated on this card. 

2. The file usage option may not be changed. 

3. The mode option may not be changed. 

4. The block size option may be changed only within 
the limits of the min and multi specifications in the 
ibmap file pseudo-operation. 

5. The unit assignment option may not be changed to 
a non-Hypertape unit if hyper was specified in the 
ibmap fdle pseudo-operation. 

6. The unit assignment option may not be changed 
to specify card equipment if the no-Hollerith-conver- 
sion option ( nohcvn ) was specified on the ibmap file 
pseudo-operation. The unit may not be changed to 
specify tape, disk, or drum equipment if the required 
Hollerith-conversion option (reqhcv) was specified. 

A setc card can be used to extend the variable field 
of a sfile card. 

The format of the sfile card is: 
1 16 



$FILE 



'filename' [options] 



Loader (IBLDR) 31 



where 'filename' is an alphameric name of 18 or fewer 
characters that identifies the file. The 'filename' must be 
enclosed by quotation marks ( 4-8 punch ) , and it must 
begin in column 16. The specifications for the options 
may be entered in any order thereafter. Specifications 
are separated from the file name and from each other 
by commas. 

Unit Assignment Options 
[, unit 1, unit 2] 

The unit 1 specification is the primary unit; the unit 
2 specification is the secondary unit used for reel 
switching. Unit specifications are described in the sec- 
tion "Unit Assignment." 

Mounting Options 

/ MOUNT 
DEFER 
JREADY 

or 
(MOUNTi\ 
'DEFERi 
iREADYi 

mount — The message is printed before execution, 
and a stop occurs for the required operator action. 

defer — The operator message and stop are deferred 
until the file is opened. 

ready — The message is printed before execution, 
but a stop does not occur. System units are normally 
given the ready option if a mounting option is not 
specified. 

The operator is notified by an on-line message of the 
impending use of an input/output unit. These options 
refer to both unit 1 and unit 2. They govern the type 
of message to be printed and the operator action re- 
quired when an input/output unit is to be put into use. 

The operation for the alternate options is the same 

as the mount, defer, or ready options except that i 

refers to a particular unit, as follows: 

i = 1 unit 1 

i = 2 unit 2 

If one of these units is specified, it supersedes any 
general mounting option specified for unit i. The 
following option, for example, causes the mount op- 
eration for unit 1 and the defer operation for unit 2: 
MOUNT,DEFER2 

If none of the options is specified, the message is 
printed before execution, and a stop occurs for the 
required operator action ( mount ) . 

File List Options 

[_' j NOLIST [ J 

list — The file appears in the operator's mounting 
instructions. 

nolist — The file does not appear in the operator's 
mounting instructions. 

If neither list nor nolist is specified, the file appears 
in the operator's mounting instruction (list). 
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File Usage Options 

/ INPUT 
i OUTPUT 
J INOUT 
^CHECKPOINTS 

or 
\CKPT 

input — The file is an input file. 

output — The file is an output file. 

inout — The file may be either an input file or an 
output file. The object program sets the appropriate 
bits in the file block. 

checkpoint or ckpt — The file is a checkpoint file. 

If neither input, output, inout, checkpoint nor 
ckpt is specified, the file is an input file ( input ) . 

Block Size Option 

|BLOCK| 

i or i = xxxx 
L ULK / 

The symbol xxxx represents a number (0000-9999) 
that specifies the block size for this file. The field may 
be omitted provided the file is included in a pool or 
group where the block size can be determined. 

If seq, sequence, or cksum is specified in the sfile 
card, the block size number must include the count for 
the one-word checksum and the block sequence word. 

Activity Option 
[,ACT = xx] 

The symbol xx represents a number (00-99) that 
specifies the relative activity of this file with respect to 
other files. The higher the number, the more active the 
file. If this field is omitted, the activity is assumed to be 
01. This value is used in determining the number of 
output buffers to assign to each buffer pool in the 
object program. 

Reel Switching Options for Unlabeled Files 

I- f ONEREEL \ -| 
) MULTIREEL! 



I or 

'reels 






onereel — Reel switching should not occur. 

multireel or reels — Reel switching should occur. 
The publication IBM 7090/7094 IBSYS Operating Sys- 
tem: Input/Output Control System, Form C28-6345, 
contains a discussion of reel switching facilities. Every 
output file switches reels if an end-of-tape condition 
occurs. 

If no option is specified, the Loader assumes that reel 
switching should not occur (onereel). 

Reel Searching Options for Labeled Files 

f j NOSEARCH M 
L'j SEARCH U 

nosearch — If an incorrect label is detected when 
opening an input file, iocs stops for operator action. 

search — iocs initiates a multireel searching pro- 
cedure for the file with the desired label. 
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If neither nosearch nor search is specified, it is 
assumed, tnst iocs will stop for operator action 
(nosearch). 

File Density Options 



( HIGH \ 

\low 

(200 
(556 
\800 



Trailer label operations are always per- 
formed in the same density as that of the 
file. 



high — The tape density switch is assumed to be set 
so that the execution of an sdh instruction will result 
in the correct density being used. 

low — The tape density switch is assumed to be set 
so that execution of an sdl instruction will result in the 
correct density being used. 

200 — The tape density switch is assumed to be set 
so that the execution of an sdl instruction will result in 
a file recording density of 200 cpi. 

556 — The tane densitv switch is assumed to be set 
so that the execution of an sdl instruction will result in 
a file recording density of 556 cpi. 

800 — The tape density switch is assumed to be set so 
that the execution of an sdh instruction will result in a 
file recording density of 800 cpi. 

This field specifies the density at which the file is to 
be read or written. If a system unit is assigned to this 
file, the specification for this unit supersedes any of the 
preceding specifications. 

If neither high, low, 200, 556, nor 800 is specified, the 
tape density switch is assumed to be set so that execu- 
tion of an sdh instruction will result in the correct 
density being used ( high ) . 

Mode Options 

'(BCD V 

JBIN I 

') MXBCD ( 

_ (mxbin ) _ 

bcd — The file is in bcd mode. 

bin — The file is in binary mode. 

mxbcd — The file is in mixed mode, and the first 
record is bcd. 

mxbin — The file is in mixed mode, and the first 
record is binary. 

If neither bcd, bin, mxbcd, nor mxbin is specified, it 
is assumed that the file is in bcd mode ( bcd ) . 

The mxbcd and mxbin options may not be specified 
for a file unless a look-ahead word is attached to each 
physical record of the file. Since this word is not 
written by iocs and cannot be programmed using 
Fortran iv or cobol languages, the mxbcd and mxbin 
options can be used with compiled programs only 
when output it handled by programs coded in the 
map language. 



Label Density Options 

r-rSLABEL \~\ 
) HILABEL I 
') LOLABEL ( 
.(.FLABEL )_ 

slarel — All header label operations are performed 
in the installation standard label specified density. 

hilabel — All header label operations are performed 
in high density. 

lolabel — All header label operations are performed 
in low density. 

flabel — All header label operations are performed 
in the same density as that of the file. 

If neither slabel, hilabel, lolabel, nor flabel is 
specified, the standard label density specification, de- 
fined by the assembly parameter slabel, is used to 
process labels. As distributed, the standard specifica- 
tion is high density. An installation can change the 
standard specification by changing the assembly param- 
eter slabel, which is in the Loader. 

Only the use of the map pseudo-operation label or 
of a slabel card denotes a labeled file, whether one of 
the label density options is specified or not. 

Block Sequence Options 



■ /NOSEQ } ' 
JSETJ— I 






(.SEQUENCE 

noseq — This specifies that the block sequence num- 
ber is not written or checked. 

seq or sequence — If reading, check the block se- 
quence number. If writing, form and write a block 
sequence number. 

If neither noseq, seq, nor sequence is specified, the 
block sequence number is not written or checked 
( noseq ) . 

Check Sum Options 



f j NOCKSUM ) 
N CKSUM 



f] 



nocksum — This specifies that the checksum is not 
written or checked. 

cksum — If reading, check the checksum. If writing, 
form and write the checksum, cksum can only be speci- 
fied when seq or sequence has been specified in the 
sfile card. 

If neither nocksum nor cksum is specified, the check- 
sum is not written or checked ( nocksum ) . 

Checkpoint Options 



r j NOCKPTS ) 1 
L'JCKPTS [J 



nockpts — This specifies that no checkpoints are 
initiated by this file. 



Loader (IBLDR) 33 



ckpts - Checkpoints are initiated by this file. afterlabel - Checkpoints are written following the 

rr _ _^j.1 - T „^-,.r,^r^r. ~~- ^t.^-r.^0 ;« c-^ar-idaA t-,i-\ /-.Vio/->lr^ IpKpl ii/T-x^n q re^p] cviritpli npr>nrc TTn'c nntirm nan pnlv 

points are initiated ( nockpts ) . be useol when the file is labeled. 

If the ckpts option is specified and this field is blank, 
Checkpoint Location Option checkpoints are written on the checkpoint files when 

[, AFTERLABEL] a reel switch occurs. 
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File Close Options 

■ f SCRATCH \—\ 
) PRINT ( 
) PUNCH ( 

l_ (hold ; _ 

scratch — The file is rewound upon termination of 
the application. 

print — The file is to be printed. It is rewound and 
unloaded upon termination of the application, print 
appears in the removal message that is printed on-line 
at the end of execution. 

punch — The file is to be punched. It is rewound and 
unloaded upon termination of the application, punch 
appears in the removal message that is printed on-line 
at the end of execution. 

hold — The file is to be saved. It is rewound and un- 
loaded upon termination of the application, hold ap- 
pears in the removal message that is printed on-line at 
the end of execution. 

If the unit assigned is the system input unit, the sys- 
tem output unit, or the system peripheral punch unit, 
there is no rewind and no message is printed. 

If neither scratch, print, punch, nor hold is speci- 
fied, the file is rewound upon termination of the appli- 
cation (scratch). 

Starting Cylinder Number Option 



WCYL 

>\ or 



CYLINDER 



VXXX' - 



The symbol x is the number (0-9) of the starting 
cylinder number of this file if it is on drum storage. If 
the file is on disk storage, the symbol xxx is the number 
( 000-249 ) of the starting cylinder number. The equal 
sign is required. The programmer must specify the 
starting cylinder number when disk-storage or drum 
storage is specified for the file. This field does not apply 
if a system unit function that is assigned to disk storage 
or drum storage is specified for the file. 

Cylinder Count Option 

(CYLCOUNT} 



E 



or 
CYLCT 



/■ 



xx is the number (00-10) of consecutive cylinders 
used by this file if it is on drum storage. If the file is 
on disk storage, xxx is the number (000-250) of con- 
secutive cylinders used by this file. The equal sign is 
required. The programmer must specify the cylinder 
count when disk storage or drum storage is specified 
for the file. This field does not apply if a system unit 
function that is assigned to disk storage or drum stor- 
age is specified for the file. 

Disk and Drum Write Checking Option 
I WRITECK] 

Write checking is performed after each disk and 
drum write sequence for this file. 



Hypertape Reel Switching Options 

-/HNRNFPV 
JHRFP ( 
')HRNFP ( 
_(HNRFP )_ 

For reel switching to occur, the programmer should 
specify whether the Hypertape is to be rewound and/ 
or protected. 

hnrnfp — Designates that the Hypertape is not to be 
rewound or file protected. 

hrfp — Designates Hypertape rewind and file pro- 
tection. 

hrnfp — Designates Hypertape rewind, but no file 
protection. 

hnrfp — Designates that the Hypertape is not to be 
rewound, but is to be file protected. 

If no option is specified, hnrnfp is assumed by the 
Loader. 

$LABEL Card 

The slabel card provides label information for the file. 
Omission of this control card indicates that the file is 
unlabeled. The fields that are present must appear in 
the order shown in the format. However, all fields ex- 
cept the first and last may be omitted by using adjacent 
commas ( , , ) . The last field is considered to be 18 char- 
acters long, with embedded blanks allowed. Files 
which are assigned units sysoui, sysous, sysppi, or 
syspp2 may not be labeled. 

All pertinent information must be on this control 
card, setc cards are not allowed. 

The format of the slabel card is: 

1 16 

$LABEL 'filename', r~ ( serial "i ~" I , [reel] 



\ home 
_ [ addres 



.(J 



"I'dateV 
■- ^ days / -J 



where 'filename' is an alphameric literal of 18 or fewer 
characters that identifies the file. It must be enclosed 
by quotation marks (4-8 punch). The 'filename' must 
start in column 16. 
Serial Number Option 

E /serial ") " 

I ° r ( 

Miome address/ - 

serial — If a tape label is desired, serial represents 
an alphameric field of five or fewer characters. Standard 
input labels are checked against this serial number if 
it is present. Standard output labels for this file will 
contain this serial number only if a reel number greater 
than 1 is specified in the reel sequence number field. 
Output serial numbers are normally taken from the 
label already present on the tape on which the first 
reel of the file is written. 
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home address — If a labeled disk file or drum file is 
desired, this field must contain two bcd characters that 
specify the norne address ~~ 2. 

The ibjob Processor itself requires a home address 
of 00 when using disk or drum as a file during proc- 
essing. 

Note: The serial number option does not change disk 
or drum format, but only tells the object program the 
content of the format. 

Reel Sequence Number Option 
The reel sequence number option is: 
[, reel] 

This is a numerical field of four or fewer characters. 
It specifies the reel sequence number of the first reel 
of a file. When the field is omitted, the sequence num- 
ber is assumed to be 1 for an output file or for an 
input file. The reel sequence number is adjusted at ob- 
ject time to reflect reel switching, and it is checked in 
standard input labels. If the field is omitted for an input 
file, the test is bypassed. If a disk label or drum label 
is desired, this field must be omitted by using two 
adjacent commas. 

Retention Cycle Options 



16 



f =xxxx L> 



BUFCT=xxx] 



IW1 

- vdavs / -• 



l-days 

date — A date can be entered in this field. The format 
is y/d where y is a one-digit or two-digit number in- 
dicating the year, and d is a number of three or fewer 
digits indicating the day of the year. The slash is used 
to separate the two numbers. This entry is not checked 
and is used merely to provide additional information 
in the label. 

days — This is a numeric field of four or fewer char- 
acters. It specifies the number of days a tape is to be 
retained from the date it is written. An attempt to 
write a labeled file on this tape before the end of the 
retention period results in an error message. If the field 
is omitted, a value of zero is assumed. 

File Identification Option 
[, name] 

This is an alphameric literal of 18 or fewer char- 
acters that specifies the file identification name in the 
label. This name is checked with the name in the input 
label. This field must follow the last comma on the card. 
If this field is omitted for an input file, the file identifi- 
cation is not checked. For an output file, this name is 
placed in the output label. If this field is omitted for an 
output file, the file identification on the existing output 
label is set to zeros. 

$POOt Cord 

The spool card designates the files that are to share 
common buffer areas. A setc card can be used to extend 
the variable field for a spool card. The format of the 
spool card is: 



$POOL 'filenamei' . . . 'filenamen' 

L'JBLK 

where each 'filename' is the name of a file to be included 
in the pool. Each 'filename' is an alphameric literal of 18 
or fewer characters and is enclosed in quotation marks 
(4-8 punch). Deck name qualification is meaningless, 
since the Loader assigns only one file block for each 
unique file name in the application. An error message 
results if a file specified as nopool in the ibmap file 
~>s6uu.o-o T ~>6ration is aiso s^eciueu on a spool or sgroup 
card, or if any other file dictionary entries for this 
named file require a pool. In this event, the nopool 
option is ignored. 
Block Size Option 



['Jblk CK [ =xxxx ] 

The symbol xxxx represents a number (0000-9999) 
that specifies the block size for this pool. If this field 
is omitted, the pool block size used is the same as the 
largest block size of a file in the pool. 

Buffer Count Option 
[, BUFCT=xxx] 

xxx is a number ( 001-999 ) that specifies the number 
of buffers to be assigned to the pool. It must be equal 
to or larger than the open count of the pool specified 
on the sgroup card. If this field is omitted, the Loader 
attempts to assign at least two buffers to each file. 

For further information concerning buffer pools, see 
"Input/Output Buffer Allocation." 

$GROUP Card 

The sgroup card is used to allocate buffer areas and to 
specify how the buffers are to be shared by a group of 
files. A setc card can be used to extend the variable 
field of the sgroup card. If the sgroup card is not used, 
the Loader attempts to assign at least two buffers to 
each file. 

The format of the sgroup card is: 

1 1(3 

$GROUP 'filenamei' . . . 'filenamen' 

[,OPNCT=xx] [,BUFCT=xxx] 

where each 'filename' is the name of a file to be included 
in the group. Each 'filename' is an alphameric literal of 
18 or fewer characters and is enclosed in quotation 
marks. Deck name qualification is meaningless, since 
the Loader assigns only one file block for each unique 
file name in the application. An error message results 
if a file specified as nopool in the ibmap file pseudo- 
operation is also specified on a spool or sgroup card, or 
if any other file dictionary entries for this named file 
require a pool. In this event, the nopool option is 
ignored. 
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Open Count Option 
[, OPNCT = xx] 

The symbol xx represents a number (01-99) that 
specifies the number of files within the group that are 
open concurrently during the execution of the program. 
This count determines the minimum buffer count 
necessary for processing the group of files. If this field 
is omitted, the count is assumed to be equal to the 
number of files in the group. 

Buffer Count Option 
[, BUFCT=xxx] 

The symbol xxx represents a number (001-999) that 
specifies the number of buffers to be assigned to this 
group. It must be equal to or larger than the open 
count of the group. If this field is omitted, the Loader 
attempts to assign at least two buffers to each file. 

For further information concerning buffer pools, see 
"Input/Output Buffer Allocation." 

$USE Card 

The $use card provides a method of specifying a par- 
ticular control section that is to be used with the object 
program at execution time. Normally, the first occur- 
rence of a control section is retained, and sections with 
the same name in other decks are deleted. The suse 
card causes the control section in a specified deck to 
be retained and all control sections with the same name 
in other decks to be deleted. A $etc card can be used 
to extend the variable field of the suse card. 
The format of the suse card is: 

1 16 

$USE deckname ( exname ) , . . . 

where the fields in the variable field consist of alpha- 
meric literals. The first six or fewer characters of the 
field are the deck name. Following the deck name is 
the external name of the control section consisting of 
six or fewer characters enclosed in parentheses. 

$OMIT Card 

The somit card provides a method of deleting a con- 
trol section from a specific deck or from all decks in 
which it appears. To delete the control section from a 
single deck, the external name for the control section 
must be preceded by the name of the deck. To delete 
the control section from all decks in which it occurs, 
it is only necessary to specify the external name for the 
control section. A setc card can be used to extend the 
variable field of the somit card. 

The format of the somit card is : 
1 16 



$OMIT 



j exname, . . . 

} deckname ( exname ) , 



..I 



where the fields in the variable field consist of alpha- 
meric literals. A literal may contain just the external 
name ( six or fewer characters ) of a control section, or 



it may contain a deck name of six or fewer characters 
followed by the external name of a control section en- 
closed in parentheses. 

$NAME Card 

The sname card may be used to change the name of a 
file or control section. A name change is required when 
the same name has been used in different decks for two 
or more distinct files or control sections, in which case 
one of them must be renamed with a unique name. 
This control card may also be used when two different 
names are used to refer to the same file or control sec- 
tion, in which case one name is replaced by the other. 
A setc card can be used to extend the variable field of 
the sname card. 

The format of the sname card is: 



1 



16 



$NAME /deckname ( exname )= exname, . 

\exname = exname, . . . 
rdeckname ( filename ) ' 
/ = 'filename', . 

\filename' = 'filename', . . . 

where the entry in the variable field consists of two 
alphameric names separated by an equal sign. The 
name on the left consists of an external name that may 
be qualified by a deck name. This external name is re- 
placed by the name to the right of the equal sign. If 
files are to be renamed, the name and the qualifier 
must be enclosed by quotation marks. 

If the external name on the left is not qualified, it is 
replaced by the name on the right wherever it occurs. 
If the name is qualified by a deck name, it is replaced 
by the name on the right only in the deck named. 

$SIZE Card 

The ssize card allows the programmer to specify the 
size of blank common. 

The format of the ssize card is: 
1 16 



$SIZE 



//=n 



where n is a decimal number that specifies the size of 
blank common. The double slash and the equal sign 
are required. If n is less than the largest blank common 
required by an object program and its subroutines, this 
specification is ignored by the Loader. 

Blank common is located in such a way that the last 
location occupied is the highest available core storage 
location as defined by the ibjob communication loca- 
tion ibjcor. The starting location of blank common is 
always an even core storage location. 

$ETC Card 

The setc card may be used to extend the variable field 
of a sfile, spool, sgroup, suse, somit, sname, or another 
setc card. It may not be used to extend the variable 
field of a slabel card. The presence of a setc card in- 
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dicates that more information is associated with the 
control card immediately preceding the $etc card. 
Therefore, the order in which setc cards occur is very 
important, and all $etc cards for a particular control 
card must immediately follow that control card. Infor- 
mation appearing in the variable field may be any 
information allowed on the control card that the $etc 
card is extending, but an individual field cannot be 
split between two cards. 

The format of the setc card is: 



$ETC 



variable field information 



Input/Output Buffer Allocation 

The rules of storage allocation pertaining to input/ 
output buffer pools and the effect of spool and sgroup 
cards on such allocation procedures are described in 
this section. 

The Loader normally assigns core storage not used 
by an object program as input/output buffers. Storage 
is not allocated by the Loader when the programmer 
is programming at the Input/Output Executor (ioex) 
level or when the programmer generates his own file 
control blocks. Since each object program is entirely 
relocatable and the amount of usable core storage can 
only be determined by the Loader, the Loader does 
the following: 

1. The storage not assigned to the system or to the 
object program is apportioned as input/output buffers 
for the files of the object program. 

2. The iocs initialization sequences of define and 
attach are generated and loaded in front of the object 



3. Storage is assigned to each pool in three steps: 

a. The pool is given one buffer for each file. If 
available storage is not sufficient for this al- 
location, execution is terminated, and an 
appropriate error message is printed. 

b. An additional buffer for each file is allocated 
to the pool. If available storage does not permit 
this allocation, a weighing factor is formed 
from the number of additional buffers desired, 
multiplied by the total activity of the files in 
that pool. The pool with the largest weighing 
factor is then assigned one buffer, if possible. 
If this assignment is not possible, the weighing 
factor of the pool is set to zero. If this assign- 
ment is possible, it is made and the weighing 
factor of the pool is reduced. The pool that 
now has the largest weighing factor is given 
a buffer. This continues until all the weighing 
factors are reduced to zero. 

c. The remainder of storage, if any, is appor- 
tioned by the ratio of the output activity of 
each pool, i.e., the sum of the activity of each 
output file in that pool compared with the sum 
of the total output file activity. 

Storage is allocated first to the pool with the greatest 
buffer size, so that the remainder may be assigned to 
a smaller pool. 

4. The amount of storage used by each buffer pool 



is: 



BUFCT*(BUFSIZ+2)+2 



Buffer Assignment with $POOL and $GROUP Cards 

spool and sgroup cards may be used to direct the as- 



ii wsiiciiii. 



d of these callin 0, sequences an in- si^nment of in^ut/out^ut buffers to certain files, pools, 



F 1 de- 
struction is generated to transfer control to the first 

instruction to be executed. 

3. iocs is coded so that any iocs-detected error that 
would have resulted in a machine stop causes the call- 
ing of an error routine that closes all files in use and 
proceeds to the next job segment or Processor applica- 
tion. 

4. If the Loader encounters a file dictionary entry 
specifying nopool, the named file is processed for unit 
assignment only. It is not attached to a buffer pool, and 
the file does not appear in the generated file list. 

General Buffer Assignment 

In the absence of spool and sgroup cards, the rules of 
input/output buffer storage allocation are: 

1. Each file is a separate reserve group. 

2. A different buffer pool is created for each distinct 
blocking size encountered. All files that have the same 
blocking size are assigned to the same pool, regardless 
of whether they are input or output files. 



or groups. Normally, because each program requires 
a relatively small amount of the total core storage, 
sufficient storage is available to assign many buffers to 
each pool. However, if the program is large or the num- 
ber of files is great, the programmer may, by using 
spool and sgroup cards, specify a more efficient assign- 
ment of buffers. The use of spool and sgroup cards is 
not considered the normal case. 

1. spool cards cause all files mentioned on the con- 
trol card to be assigned to the same buffer pool. If any 
of the files are also specified on sgroup cards, all files 
specified in that group are automatically associated 
with the pool. No other files, not even those with block 
size equal to that of the pool, are assigned to the speci- 
fied pool. 

2. If a buffer count is specified on a spool card, that 
pool is given exactly that number of buffers. Checks 
are made to ensure that the specified count is sufficient. 
A sufficient count is defined as the sum of the number 
of nongrouped files in the pool plus the buffer counts 
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of all groups of that pool. If a buffer count is not speci- 
fied, the pool is allocated buffers as described in the 
section "General Buffer Assignment." 

3. If block size is not specified on a spool card, the 
size is the maximum blogk size of the files assigned to 
that pool. 

4. $group cards cause the specified files to be 
grouped under a single reserve group control word. If 
a buffer count is specified, this count is used and must 
be at least equal to the open count of those files that 
are open concurrently. If the open count is not speci- 
fied, it is equal to the number of files in the group. If 
the buffer count is not specified, extra buffers are allo- 
cated to the pool to which that group is assigned. This 
is described in item 3c of the section "General Buffer 
Assignment." 

5. Groups can be created within specified pools by 
naming at least one of the files in the group on a spool 
card, as well as on the $group card. 



Unit Assignment 

This section describes the unit assignment specifica- 
tions for the $file card, the use of intersystem unit as- 
signment, and the order in which files are assigned to 
units. 

Unit Assignment Notation 

The following notation is used to explain unit assign- 
ment specifications: 



NOTATION 

X 

p 
I 

k 

a 
m 

s 

M 

D 
H 

N 



EXPLANATION 

a real channel ( A through H ) 
a symbolic channel ( S through Z ) 
an intersystem channel ( J through Q ) 
a unit number ( through 9 ) 
the access mechanism number ( or 1 ) 
the module number ( through 9 ) 
the Data Channel Switch (also called inter- 
face) (Oor 1) 

the model number of a 729 Magnetic Tape 
Unit (II, IV, V, or VI) 
a 1301/2302 Disk Storage 
a 7340 Hypertape Drive 
a 7320 Drum Storage 



Unit Assignment Specifications 



NOTATION 

blank 
M 

X 



X(k) 



EXPLANATION 

Use any available 729 Magnetic Tape Unit. 
Use any available 729 Magnetic Tape Unit, 
model M, where M is either II, IV, V, or VI. 
Use any available 729 Magnetic Tape Unit 
on channel X. 

Use any available 729 Magnetic Tape Unit 
on channel P. 

Use the kth available 729 Magnetic Tape 
Unit on channel X. The parentheses are re- 
quired. 



NOTATION EXPLANATION 

PM Use any available 729 Magnetic Tape Unit, 

model M, on channel P. 

P(k)M Use the kth available 729 Magnetic Tape 

Unit, model M, on channel P. The paren- 
theses are required. 

I(k) Use the kth available 729 Magnetic Tape 

Unit on channel I. The parentheses are re- 
quired. This specification can be used for 
input and output units. 

I(k)M Use the kth available 729 Magnetic Tape 

Unit, model M, on channel I. The paren- 
theses are required. This specification can be 
used only for output units. 

I(k)R Use the kth available 729 Magnetic Tape 

Unit on channel I, and release the unit from 
reserve status after the application has been 
completed. The parentheses are required. 

XDam/s Use 1301/2302 Disk Storage on channel X, 

access mechanism number a, module num- 
ber m, and data channel switch s. 

XNam/s Use 7320 Drum Storage on channel X, access 

mechanism number a (0), module number 
m (0, 2, 4, 6, or 8), and data channel 
switch s. 

XHk/s Use a 7340 Hypertape Drive on channel X, 

unit number k, and data channel switch s. 

IN, INI, IN2 Use the system input unit ( SYSIN1 ) and the 
alternate system input unit (SYSIN2) as the 
primary and secondary units, respectively. 

OU, OUl,OU2 Use the system output unit (SYSOU1) and 
the alternate system output unit (SYSOU2) 
as the primary and secondary units, respec- 
tively. 

PP, PP1, PP2 Use the system peripheral punch unit 
( SYSPP1 ) and the alternate system periph- 
eral punch unit (SYSPP2) as the primary 
and secondary units, respectively. 

UTk Use the system utility unit, number k. 

RDX Use the card reader on channel X. If a card 

reader is specified, OPTHCV or REQHCV 
must be specified in the FILE pseudo- 
operation. 

PRX Use the printer on channel X. 

PUX Use the card punch on channel X. An as- 

terisk in the unit 2 field indicates that the 
secondary unit for a file is to be a unit on 
the same channel and of the same model 
type as the primary unit. This unit, if avail- 
able, is assigned after all other unit assign- 
ments have been made. 

INT The file is an internal file. 

NONE No units are assigned. A file control block is 

generated but does not refer to a unit control 

block./ 

/ 

Intersystem Unit Assignment 

To provide for the passage of data through a series of 
related applications, intersystem unit assignments are 
made. The use of this specification allows an object 
program to write an intermediate output file on a unit 
and to reserve that unit for later use as input or output 
for an object program in a different application. This 
is done by using symbolic channels J through Q. 

When a sfile card for an input file is encountered 
by the Loader, the primary intersystem channel and 
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relative unit, if present, are used for scanning the unit 
control blocks to find a matching intersystem unit, i.e., 
a unit in reserve status that has the same intersystem 
channel designation and relative unit. If a match is 
found, the input file from the sfile card is assigned to 
that physical unit. If a match is not found, a tape as- 
signment error is noted and execution is not allowed. 

For an intersystem unit designated as output, the 
same scanning of the unit control blocks is performed. 
However, unlike the input file processing, if a match 
is not found, the intersystem channel is treated as a 
symbolic channel ( S through Z ) and a reserve flag and 
indicative data are placed in the unit control block. 

If an error occurs, either prior to or during execution 
of a program that uses intersystem output units, these 
units are removed from reserve status and are returned 
to the availability chain. Subsequent references to these 
intersystem units as input causes a tape assignment 
error, and an error message is written on the system 
output unit. 

Order of Assignment 

Files are assigned to units in the following order: 

1. All files on system or card units are assigned first. 

2. Input files on intersystem channels are assigned. 
If the designated unit does not already exist in reserve 
status, a tape assignment error is noted and execution 
is not allowed. 

3. Files on specified (real) channels are assigned. 
If during steps 1, 2, and 3 there are insufficient units 

on the requested channels, a message is printed indicat- 
ing that the object-time tape assignment can not be 
completed because of insufficient units on the specified 
channels. 

4. Output files on intersystem channels are assigned. 
Those intersystem channels with the largest require- 
ment are processed first. Starting with the highest real 
channel, the channels are processed to determine 
whether the intersystem channel requirements can be 
met. When a real channel is found that contains suf- 
ficient available units for the intersystem channel, that 
real channel is chosen. If there is no real channel that 
can meet the intersystem channel requirements, a real 
channel is chosen to assign as many of the intersystem 
units to the channel as possible. The remaining inter- 
system units are now assigned by again finding the 
intersystem channel with the greatest requirements 
and matching it with a real channel. 

5. Files on symbolic channels are assigned. The pro- 
cedure is the same as that described under intersystem 
assignment. 

6. Only files with model specifications are assigned. 
Units are chosen, starting at the highest unit number 
of the first available channel. 



7. Files with omitted specifications are assigned. If, 
during steps 4, 5, 6, or 7, there are insufficient units 
available for assignment, a message is printed indicat- 
ing that object time tape assignment can not be com- 
pleted because of insufficient units on the system. 

8. Secondary units are assigned with the primary 
units and on the same channel as the primary units. 
When the unit 2 specification is omitted, the secondary 
unit is the same as the primary unit. If the primary unit 
is a Hypertape drive, the secondary unit must also be 
a Hypertape drive. 

Over/ay Feature of the Loader 

The overlay feature provides a method for processing 
programs that exceed the capacity of core storage. The 
programmer divides the program to be executed into 
links. A link can contain one or more program decks. 
One of the links ( called the main link) is loaded into 
core storage with the overla v subroutine and the tables 
required for program execution, and it remains in core 
storage throughout the execution of the program. The 
Loader writes the other links ( called dependent links ) 
on an external storage unit. The external storage unit 
can be disk storage, drum storage, or magnetic tape. 
The dependent links are written in a scatter-load for- 
mat and have block sizes of 464 words for 729 tape 
and 1301 disk storage, 524 words for 7320 drum storage, 
or 969 words for 2302 disk storage, depending on 
which device the Loader is assembled for. 

The Overlay Structure 

Figure 17 is an example of the structure of an overlay 
application. In Figure 17, the vertical lines represent 
links into which the program is divided. The horizontal 
lines from which the vertical lines proceed indicate the 
logical origins of the links. 

Note that, as Figure 17 implies, a continuous chain 
of links is always in core storage, from the deepest link 
required, back through whatever links precede it, to 
the main link. For example, in Figure 17 the possible 
configurations of links are: 

1. link ( main link only ) 

2. links and 1 

3. links and 2 

4. links and 3 

5. links and 4 

6. links 0, 4, and 5 

7. links 0, 4, and 6 

The loading of a link is caused by the execution of 
a call from a link that is presently in core storage to a 
link that is not in core storage. When a link is loaded, 
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it overlays the link in core storage with the same logical original link overlaid. 

origin, and it overlays any links in core storage with As noted above, a continuous chain of links is always 

deeper logical origins extending downward from the in core storage. For example, if link 6 in Figure 17 
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Figure 17. Example of Overlay Structure 



were to be called from link 0, link 4 would also be 
loaded, even though specific reference was not made 
to link 4. 

If a link already in core storage is called, it is not 
reloaded. 

Each deck within a link is called, or referred to, by 
the map pseudo-operation call. The call pseudo- 
operation is the only operation that causes overlay. 
Fortran and cobol statements that are translated into 
a call pseudo-operation that refers to another deck 
can be used to cause overlay. A call statement is not 
needed after every link. 

The CALL Statement 

The primary rule regarding call statements that cause 
links to be loaded is that, normally, no deck may either 
directly or indirectly call for itself to be overlaid. 
The following types of call statements are valid: 

1. A call toward a deeper link in the same chain is 
permissible. This type of call may or may not cause a 
link to be loaded, depending on whether or not the 
link is already in core storage. 

2. A call within a link is always permissible. This 
type of call does not cause a link to be loaded. 



3. A call from a deeper link to decks within the same 
chain of links toward the main link is permissible, 
provided the deck that it calls does not cause the orig- 
inating deck to be overlaid. 

If an invalid call statement is used, the program is 
not executed unless noflow is specified in the variable 
field of the $ibjob card. 

Since the overlay structure is defined at load time, all 
call statements that cause overlay must be defined at 
load time. A call statement of the form: 

CALL ** 

where the address is supplied at execution time, cannot 
initiate overlay. 

Referring to the overlay structure in Figure 17, the 
following examples may be given: 

1. A call from deck 3 to deck 4 is permitted. A call 
within the same link never causes a link to be loaded. 

2. A call from deck 2 to deck 12 is permitted. This 
call from link to link 5 initiates the loading of links 
4 and 5. 

3. A call from deck 12 to deck 9 is permitted. This 
call is in the chain of links toward the main link. 

4. A call from deck 13 to deck 3 is not permitted. 



T nir noil nont 



*V.< 



lnorlinrr r\T tiinlr 1 



H-iororvir rvirorla^ 



ing link 6, which contains the deck in which the call 
statement originated. 

5. A call from deck 11 to deck 9, followed by a call 
from deck 9 to deck 13, is not permitted. This call from 
deck 11 to deck 9 is valid, but, since deck 9 contains a 
call to deck 13, link 6 would overlay link 5, which con- 
tains the deck in which the call statement originated. 

Virtual Control Sections 

During the analysis of virtual control sections, virtual 
control sections other than the call type are also 
checked for validity. This type of virtual reference 
cannot cause a link to be loaded, but may cause an 
error if reference is made to a section that is not in core 
storage. The following rules should be considered: 

1. A reference to a control section in a deeper link 
in the same chain is permissible, but it may be in error 
if the deeper link has not been loaded into core storage. 
If logic or dlogic was specified on the sibjob card, a 
warning message is printed. 

2. A reference within a link is always permissible. 

3. A reference from a deeper link to a control section 
within the same chain of links toward the main link is 
always permissible. 

4. A reference to a section that is not in the allow- 
able chain of links is not permitted, since, by the 
definition of overlay structure, the section referred to 
would not be in core storage. If noflow is specified in 
the variable field of the sibjob card, this type of refer- 
ence is permitted. 
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Storage Allocation During Execution 

Figure 18 illustrates how the overlay structure in Figure 
17 would be assigned to core storage. Links having the 
same logical origin are loaded starting at the same 
absolute location, unless the programmer has specified 
an absolute loading address for one or more links. 
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Figure 18. Overlay Core Storage Allocation 

Library subroutines in the main link are loaded fol- 
lowing the input decks that constitute the main link. 
Nearly all of the Library subroutines can be included 
in deeper links by using a sinclude card. The excep- 
tions are noted under "sinclude Card." The input/ 
output buffers occupy the unused core storage area 
between the longest possible link configuration and the 
highest available core storage location. The Fortran 
common area, if used, has priority and is assigned the 
highest available core storage location and, therefore, 
is assigned following the input/output buffers. 

Overlay Control Cards 

Two control cards are used with the overlay feature 
of the Loader. The sorigin card is used to specify the 
logical origin of links. The sinclude card is used to 
specify a deck ( or any control section ) be loaded with 
a link other than the one with which it would normally 
be loaded. 

The order in which options are specified on the con- 
trol cards is not significant unless otherwise specified. 



$ORIGIN Card 

The logical origins that are specified on sorigin cards 
govern the structure of an overlay deck. The decks 
appearing first in the program are assigned to the main 
link and are usually not preceded by a sorigin card. A 
sorigin card must precede the main link if the overlay 
link-loading subroutine .lovry is included in the 
input program rather than being read from the Sub- 
routine Library. When a sorigin card is used to desig- 
nate the main link, the logical origin specified by this 
card cannot be used on succeeding sorigin cards or an 
error condition occurs, since more than one main link 
would then be specified. 

The sorigin card initiates an overlay link for the 
decks that follow. Decks following the sorigin card 
are assigned to the same link until the occurrence of 
another sorigin card, a sentry card, or an end-of-file 
condition. 

All pertinent information must be on this control 
card. The setc card may not be used to extend the 
variable field information. 

The following text indicates the options that may be 
specified on the sorigin card. 

The format of the sorigin card is: 

1 16 

$ORIGIN logical origin [, options] 

where the logical field must be specified and must be 
the first information contained in the variable field. 
The field contains an alphameric literal of six or fewer 
characters, one of which must be nonnumeric. Char- 
acters that cannot be used are parentheses, equal signs, 
commas, slashes, quotation marks, and embedded 
blanks. 

E absolute "1 
origin J 

This field contains five or fewer numeric characters 
specifying an absolute location at which the link is to 
be loaded. If the number is expressed in octal form, an 
alphabetic O must precede the number. The field is 
used only if a program requires that a link be loaded at 
a specific location. It has no effect on the overlay struc- 
ture. It merely determines the loading point for this 
particular link and all those links following that are 
without sorigin cards to specify different absolute 
origins. 

Unit Specification Options 

r j SYSuT2 n 

L'jSYSxxx fj 

This field specifies the input/output unit on which 

the dependent links are written. Any of the following 

seven system units may be specified: 

SYSUT2 ( or UT2 ) SYSLB4 ( or LB4 ) 

SYSUT3 ( or UT3 ) SYSCK1 ( or CK1 ) 

SYSLB2 ( or LB2 ) S YSCK2 ( or CK2 ) 

SYSLB3 (orLB3) 
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Note: sysck2 is not available if debugging has been 
requested. 

If the system library unit syslb2, syslb3, or syslb4 is 
specified and is also used to store the system com- 
ponents, an error message is written on the system 
output unit and execution is not allowed. 

If the field is omitted, the system utility unit ( sysut2 ) 
is assigned. It is assumed that the unit chosen is in 
ready status and that it is not used for any purpose 
other than loading links during execution. 

Rewind Options 
H NOREW M 

norew — The input/output unit containing the link 
is not to be rewound after the link is loaded. 

rew — The unit is to be rewound. 

If neither norew nor rew is specified, the unit is not 
rewound (norew). 

$INCLUDE Card 

The sinclude card specifies that the decks and/or the 
control sections named in the variable field be included 



in the link in which this control card appears, rather 
than in the link to which they would normally be as- 
signed. 

The format of the sinclude card is : 
1 16 

$INCLUDE i deckname },... 

I exname ) 

The subfields of the variable field contain alphameric 
literals that specify either a deck name (usually a 
library subroutine) or a real control section name of 
nonzero length ( usually a block of data or coding ) to 
be included in this link. 

If a library subroutine is specified, the deck name of 
the subroutine (and not one of its entry points) must 
be given. Library subroutines are placed automatically 
in the main link, so that they are available to all sub- 
sequent links. A library subroutine may, however, be 
assigned to a dependent link by means of a sinclude 
card. A subroutine or control section cannot be loaded 
in more than one link. If it is called from more than 
one link, it must be loaded in a link that is available 
to all calling links. 




Figure 19. Sample Overlay Control Card Deck 
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The following subroutines must always be in the 
main link and, therefore, may not be specified on a 
sinclude card: 

1. .fptrp — Floating-Point Trap Subroutine 

2. .lxcon — Execution Control Subroutine 

3. .lovry — Overlay Link Loading Subroutine 

4. The subroutine(s) designating the level of iocs 
used by the object program. The object-time debugging 
routines, if used, may not be specified on a sinclude 
card. The Library iocs routines .iodef, .iocss, .iocs, 
mr'ejf .iocsd .iocsl ina u not be specified on a sinclude 



card. 

The variable field of a sinclude card may be ex- 
tended over more than one card, using either the setc 
card or another sinclude card. The sinclude card may 
appear immediately following the sorigin card specify- 
ing the link, between the decks within the link, or 
immediately following the last deck of the link. 

Control Card Usage 

Figure 19 illustrates how a deck would be set up to 
produce the program structure given in Figure 20. 

In Figure 19 the sorigin card, which first uses logical 
origin alpha, immediately follows the main link ( decks 
1 and 2 ) . All links using logical origin alpha, therefore, 
proceed from the main link. Every new logical origin 
encountered on a sorigin card specifies that all links 
using this logical origin will proceed from the previous 
link. The sorigin cards containing the logical origins 
beta and gamma are placed after the links from which 
they proceed. In this manner, the sorigin cards are used 
to form the overlay structure. 



The following examples are given to aid the pro- 
grammer in the use of overlay control cards. To in- 
clude the subroutine flog and the control section xyz 
in the link that contains deck 1, the sequence shown in 
Figure 21 could be used. 

When a deck or section is assigned to a link by means 
of a sinclude card, care must be taken that the link 
incorporating the deck or control section be available 
to all other links that refer to or call the deck or section. 

If a sinclude card is used to move a block of instruc- 
tions or data from a deck to some other link, it is pos- 
sible to cause the external link file to be written in a 
format that cannot be used efficiently during execution. 
For example, in Figure 22 the instructions or data in 
section xyz that are to become part of link A are not 
encountered by the Loader for processing until after 
link A and a portion of link B have been written onto 
the system utility unit (sysuts). Therefore, on sysut3, 
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portion of link A. If sysuts is a tape file, some tape has 
to be spaced over when loading link A in order to load 
the xyz portion. This situation can usually be avoided 
by specifying a unique unit for the storing of the link 
that contains the sinclude card. 

It should be noted that the previously mentioned 
condition occurs only when the section specified on 
the sinclude card is internal to some deck and contains 
text. This condition does not occur when assigning 
library subroutines or control sections that do not con- 
tain text to other links by means of the sinclude card. 



ALPHA 



BETA 



Deck 1 
Deck 2 



Deck 8 



GAMMA 



Deck 9 



Deck 10 



Deck 1 1 



Deck 3 
Deck 4 



Deck 7 



Deck 5 



Deck 6 



Figure 20. Overlay Structure for Sample Control Card Deck 
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SORIGIN ALPHA 
SINCLUDE FLOG, XYZ 



Figure 21. Overlay Control Cards to Include Subroutine FLOG 
and Control Section XYZ in Link Containing Deck 1 



A.SYSUT3 (LINK A) 



MNCLUDE XYZ 

iORIGIN B.SYSUT3 (LINK B) 

IIBLDR DECK! 



ilbLDR 0ECK2 



(CONTAINS XYZ) 



Figure 22. Inefficient Use of $INCLUDE Card to Include Con- 
trol Section XYZ in Link A 
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CALL Transfer Vector 

During loading, an analysis is made of all call state- 
ments in the program. If a call statement causes 
overlay, the transfer address of the call statement is 
modified to refer to a transfer vector of the form: 



pfx 
TXI 



entry point, , link number 
.LOVRY 



For example, the statement: 

CALL .SUBPR 

may be modified by the Loader to: 
CALL .TV001 

and starting at location .tvooi, the Loader would gen- 
erate the following two words: 



pfx 
TXI 



.SUBPR, link number 
.LOVRY 



This transfer vector is constructed by the Loader and 
is stored with the object program in a generated con- 
trol section called .lvec. During execution, if the called 
deck was loaded into core storage, pfx is set to txl and 
a transfer is made to the entry point. If the called deck 
was not loaded into core storage, pfx is set to txh and 
a transfer is made to the link loading subroutine .lovry. 
This subroutine loads the required links and resets 
all the transfer vector words involved to indicate 
properly the load status of the links. 

If logic is specified on the sibjob card, the absolute 
location of .lvec is indicated in the logic listing. 

$ENTRY Card With Overlay 

When a sentry card is used to name the first instruction 
to be executed in a program using overlay, the instruc- 
tion named must be contained in the main link. 
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Subroutine Library (IBLIB) 



The Subroutine Library contains relocatable sub- 
routines for use by both the system itself and the object 
program. These subroutines are incorporated into the 
object program at load time by the Loader, either at 
the programmer's request or automatically in response 
to program requirements. Subroutines may be added to 
and deleted from the Subroutine Library by using the 
Librarian, as described in the section "The Librarian." 

The Subroutine Library consists of system, cobol, 
and Fortran iv subroutines. The operating system uses 
certain Library subroutines for maintaining control and 
communication among the system programs. The cobol 
subroutines include subroutines needed for movement, 
conversion, input, and output of data. The Fortran iv 
section of the Library includes the Fortran mathe- 
matics library, the Fortran input/output library, and 
the Fortran utility library. The Fortran mathematics 
subroutines and certain Fortran utility subroutines 
available for use by the applications programmer are 
described in this section. The remainder of the sub- 
routines are used only by the system and the compilers, 
and are described in the section "Subroutine Library 
Information." 



FORTRAN IV Mathematics Library 

The Fortran iv mathematics library contains three 
types of subroutines: single-precision, double-precision, 
and complex. Fortran iv, map, and cobol programmers 
can use these subroutines to perform mathematical com- 
putations. Some subroutines are capable of performing 
more than one kind of computation. These capabilities 
are called "functions." Each function has its own entry 
point in the subroutine. 

The library exists in two versions: a 7090 version and 
a 7094 version. The main difference between them is 
the way double-precision functions are evaluated. In 
the 7090 version the closed subroutine fdas has been 
added to simulate double-precision instructions. In 
the 7094 version double-precision instructions perform 
the computations. These instructions save time and 
core storage space. They are also more accurate for 
very small double-precision numbers when used in 
conjunction with the double-precision floating-point 
trap routine. This routine is described in the section 
"Floating-Point Trap Subroutine." 



Calling Sequences to FORTRAN IV 
Mathematics Subroutines 

The calling sequence to a subroutine function depends 
on the programming language used. In each case, how- 
ever, the programmer specifies an entry point and the 
names of one or more core storage locations containing 
arguments. Each function has its own entry point. The 
name of this entry point is distinct from the name of 
the subroutine containing it. These names are con- 
sidered as control sections and as such can be changed 
through the use of the sname card. ( See "$name card.") 
Input to a subroutine normally consists of arguments. 
In a cobol program there must also be a core storage 
location in which the subroutine places the result of its 
computation. The general form of a calling sequence in 
each programming language is shown in Figure 23. The 
specific forms for calling the various functions are 
shown in Figures 25A, 25B, 25C, and 26. 





Calling Sequences For 


Calling Sequences For 


Source 


Functions Having 


Functions Having 


Language 


One Argument 


Two Arguments 


FORTRAN IV 


y = entry point (argument) 


y = entry point (argl, arg2' 




The answer is stored 


The answer is stored 




in y. 


in y. 


MAP 


CALL entry point 


CALL entry point (argl. 




(argument) 


arg2). 




The answer is left in 


The answer is left in 




the AC or AC-MQ. 


the AC or AC-MQ. 


COBOL 


CALL 'cobol entry point' 


CALL 'cobol entry point' 




USING result, argument. 


USING result, argl, 




The answer is stored 


arg2). 




in result. 


The answer is stored 
in result. 



Figure 23. General Form of Calling Sequences to FORTRAN IV 
Mathematics Subroutines 



Arguments 

Most arguments used in the mathematics subroutines 
must be normalized floating-point numbers. (Excep- 
tions are in the fxpi, fxp2, fdxi, and fmtn subrou- 
tines.) 

A double-precision argument is contained in two ad- 
jacent core storage words. The first word contains the 
high-order portion of the argument and is referred to 
as its location. The second word contains the low-order 
portion of the argument. 
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A complex argument is also contained in two ad- 
jacent words. The first word contains the real portion 
of the argument and is referred to as its location. The 
second word contains the imaginary part of the 
argument. 

map programmers coding for the 7094 must use an 
even pseudo-operation to store each double-precision 
or complex argument, starting at an even core storage 
location. Otherwise, as soon as a double-precision in- 
struction in a subroutine refers to the argument, a 
floating-point trap occurs. On the 7090 or 7094 II such 
core storage alignment is not necessary. 

cobol programmers using data-types 4 and 5 on a 
7094 cannot use the double-precision or complex sub- 
routines. (For a description of data-types, see IBM 
7090/7094 IBSYS Operating System, Version 13; 
COBOL Language, Form C28-6390. ) 

Results 

Each function produces a single result. Double- 
precision and complex functions produce two-word 
results. For Fortran iv programs, the single-precision 
result is stored in the leftmost variable in the calling 

sequence. For cobol programs, the result is stored in 
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are left in the ac. The high-order portion of double- 
precision results is left in the ac, and the low-order 
portion in the mq. The real portions of complex answers 
are left in the ac, and the imaginary portions in the mq. 

Error Handling for FORTRAN IV Mathematics 
Subroutines 

There are certain limits on the range of numbers over 
which an input argument yields meaningful results. 
These ranges are shown in Figures 25A, 25B, 25C, and 
26 for each subroutine. 

When the valid argument range for a subroutine is 
exceeded in a program, the execution-error-monitor 
subroutine fxem prints an error message. It then either 
terminates execution or supplies a conventional answer 
and returns control to the program. The fxem sub- 
routine is described under "fortran iv Utility Library" 
in the section "Subroutine Library Information" in 
Part 2. 

Among the conventional answers that fxem may 
give is the largest possible positive floating-point num- 
ber. This is 2 127 - 2 100 in single-precision numbers, or 
2127 _ £73 f or double-precision numbers. For brevity, the 
number is written as O in Figures 25A, 25B, and 25C. 

The distributed version of fxem always supplies a 
conventional answer when entered from a mathematics 
subroutine. Except in exceptional circumstances, how- 
ever, it is safer to terminate execution. The user can 
provide for termination by presetting the fxem control 
bits as described under "fortran iv Utility Library." 



Error Codes 

In each of Figures 25A, 25B, and 25C there is a column 
headed "Error Code." The numbers in this column cor- 
respond to the respective option control bit position 
in the first and third words of the fxem control section, 
i.e., the optwdi and optwt>3 described under "fortran 
iv Utility Library." 

As an illustration of how this code is used, consider 
what happens when the single-precision square root 
subroutine encounters a negative (i.e., invalid) argu- 
ment. In this case, the square root subroutine, upon 
detecting the negative argument, makes an entry into 
the fxem subroutine, specifying error code 13. Upon 
receiving the error code, fxem examines bit 13 of 
optwdi. If bit 13 is zero, fxem prints the appropriate 
error message and terminates execution. If bit 13 is one, 
this means that the option for computing the square 
root of the absolute value of the argument will be 
taken; accordingly, after printing a warning message, 
fxem returns control to the square root subroutine, 
which changes the sign of the argument and proceeds 
upon its normal course. 

Floating-Point Trap Subroutines 

The computer must be in the floating-point trap mode 
for the proper operation of the Fortran iv mathematics 
subroutines. It is in this mode at the start of object 
program execution and continues so until it executes 
an lftm instruction. Floating-point traps are handled 
by the standard floating-point subroutine on a 7090 
and by the standard or its alternate on the 7094. The 
difference between these subroutines is discussed under 
"Alternate 7094 Floating-Point Trap Subroutine." 

Floating-Point Overflow 

Except for the subroutines dealing with complex num- 
bers, floating-point overflow will never occur because 
the arguments are screened upon entry. If an argument 
is such that it could cause an overflow, it is immediately 
treated as out of range and control passes to the fxem 
subroutine. 

For some of the complex subroutines the occurrence 
of floating-point overflow is possible even though both 
the real and imaginary parts of a given argument them- 
selves lie within the valid argument range. This is be- 
cause either the real or the imaginary part of certain 
complex answers is a function of both the real and the 
imaginary part of the argument. If this happens, it is 
too costly in both core storage space and execution 
time to screen out invalid arguments prior to the par- 
ticular arithmetic operation that could cause the over- 
flow. An occurrence of such an overflow causes a 
floating-point trap and an overflow error message. Since 
the floating-point trap subroutine sets an overflowed 
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register to Q, before proceeding, the answer produced 
by a complex subroutine is unreliable. 

Floating-Point Underflow 

Several of the mathematics subroutines can cause 
floating-point underflow. An underflow causes a float- 
ing-point trap. The floating-point trap subroutine then 
sets the register involved to a signed zero and re- 
turns control to the subroutine from which the trap 
originated. Often an underflow is irrelevant to the 
computation of the function involved. This is true with 
low-order or remainder underflow for the single- 
precision or complex function routines. Setting zero 
into the involved register does not in any way influence 
the accuracy of answers. Both a double-precision low- 
order underflow and a high-order underflow are rele- 
vant to the accuracy of answers. 

A relevant underflow occurs only when the answer 
iteslf is very close to the underflow threshold. Since 
numbers below this threshold cannot be represented in 
the machine registers, setting underflowed registers to 
zeros yields the greatest possible accuracy. 

Alternate 7094 Floating-Point Trap Subroutine 

As distributed, the system tape for the 7094 Subroutine 
Library has both a standard and an alternate floating- 
point trap subroutine. Each has the entry point name of 
.fptrp. The user must select the subroutine he wants. 

The two subroutines differ only in the treatment of 
mq underflow resulting from a double-precision in- 
struction. The alternate subroutine returns control to 
the trapped subroutine, with the mq unchanged (i.e., 



nut act lu z.ciu / . r un <Jt-uiL s 



caiicc is uius retained. 



No errors will result from this action except when a 
map program attempts independent manipulation of 
high-order and low-order parts of double-precision 
numbers. 

The alternate subroutine is considerably more accu- 
rate when the result of the arithmetic operation is less 
than 10~ 30 - 7 in magnitude. It is also more accurate 
when used with double-precision subroutines. The 
accuracy figures for double-precision subroutines in 
Appendix H are based on the use of the alternate sub- 
routine. Figure 24 shows the difference in accuracy 
between the two versions. 



7090 Double-Precision Simulation 

Most of the 7090 double-precision mathematics sub- 
routines use fdas, a common utility subroutine for the 
rapid simulation of double-precision instructions, fdas 
may also be called by a 7090 map program. The fdas 
calling sequence and specifications are shown in Ap- 
pendix H. 



Mathematical 
Subroutine 


Argument 


Maximum Accuracy 
Using Standard 


Maximum Accuracy 

Using Alternate 

c..u,„, .»:.,„ 


FDXP 


- 89.41 5986<x 
<- 70.701 01 3 


8 decimal digits 


16 decimal digits 


FDSC 


0<lxl<2- 10 V 


In addition, if <C Argument <C 2 -102 and if the low-order part of 
the argument is inexact because the alternate subroutine is absent, 
then this inaccuracy is reflected in the answer produced by FDSQ 
and FDAT. The answer is then accurate to a maximum of only 8 
decimal digits. 



Figure 24. Accuracy of Standard Versus Alternate 7094 Floating- 
Point Trap Subroutines 

Evaluating Accuracy 

To evaluate the accuracy of the subroutines, see Ap- 
pendix H, "fortran iv Mathematics Subroutines — 
Algorithms, Accuracy, and Speed." This appendix also 
contains the algorithms that are the mathematical basis 
for each subroutine. 

Subroutine Reference Tables 

Figures 25A, 25B, 25C, and 26 contain information on 
the Fortran rv mathematics subroutines for quick 
reference. 

Information such as algorithms, accuracy statistics, 
and average speeds is contained in Appendix H. Core 
storage requirements are listed in Appendix I. These 
tables are self-explanatory, except for the symbol O, 
which has been defined previously under "Error Han- 
dling for Fortran rv Mathematics Subroutines." 

Note: Some of the ranges in the following figures are 
represented in powers of 2. The corresponding ap- 
proximate decimal values are as follows: 

2- m = 5.878 x 10" 30 
2 20 = 1.049 X 10 e 
2 25 = 3.355 X 10 7 
2 50 as 1.126 X 10 15 
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Subroutine Name 


Definition 


Calling Sequences 
F = FORTRAN IV 
M = MAP 
C = COBOL 


Valid Argument Range 


Error 
Code 


Options 


If Argument 
Range Is 


Then The 
Answer Is 


square root FSQR 


y = x 2 


F: y = SQRT(x) 
M: CALL SQRT(x) 
C: CALL '.CSQRT' 
USING y, x. 


O^x 


13 


x<0 


Ixl* 


exponential FXPF 


y=e* 


F: y = EXP(x) 
M: CALL EXP(x) 
C: CALL '.CEXP' 
USING x, y. 


x^88.029692 


8 


x> 88.029692 


n 


exponentiation 
fixed-point base 
and fixed-point 
exponent FXP1 


Y =;> 


F: y = i**j 
M: CALL .XP1 .(/,/) 
C: CALL '.CXPT 
USING y,i,j. 


i^O, j^O 


1 


;=o 
;=o 





2 


i=0 

»<o 





exponentiation 

floating-point base 
and fixed-point 
exponent FXP2 


_ i 
y-x 


F: y — x**i 
M: CALL .XP2.(x, i) 
C: CALL '.CXP2' 
USING y, x, i. 


x=^0, i^O 


3 


x = 

;=o 





4 


x = 

<o 





exponentiation 

floating-point base 
and floating-point 
exponent FXP3 


y = x° 


F: y = x**o 
M: CALL .XP3. (x,a) 
C: CALL '.CXP3' 
USING y, x, a. 


x>0and a^O 


5 


x<0 
a^0 


lxl d 


6 


x=0 
o = 





7 


x=0 
a<0 





logarithm FLOG 


y = log e (x) 


F: y = ALOG(x) 
M: CALL ALOG(x) 
C: CALL '.CALOG' 
USING y,x. 


0<x 


9 


x = 


-fi 


10 


x<0 


log« Ixl 


y = logio(x) 


F: y = ALOG10(x) 
M: CALL ALOGlO(x) 
C: CALL '.CAL10' 
USING y,x. 


0<x 


9 


x = 


-Q 


10 


x<0 


logw Ixl 


sine/cosine FSCN 


y = sine(x) 

(x expressed 
in radians) 


F: y = SIN(x) 
M: CALL SIN(x) 
C: CALL '.CSIN' 
USING y,x. 


lxl<2" 


12 


lxl^2 25 





y = cosine(x) 

(x expressed 
in radians) 


F: y = COS(x) 
M: CALL COS(x) 
C: CALL '.CCOS' 
USING y,x. 


lxl<2" 


12 


lxl^2 25 





tangent/cotangent 
FTNC 


y = tan(x) 
(x expressed 
in radians) 


F: y=TAN(x) 
M: CALL TAN(x) 
C: CALL '.CTAN' 
USING y,x. 


lxl<2 20 and x may not 
be an odd integral 
multiple of -7- (see 
note) 


73 


lxl^2 20 





74 


x^fc-^- where k 
is an odd 
integer 


n 



Figure 25A. Single-Precision Subroutines in the FORTRAN IV Mathematics Library 
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Subroutine Name 


Definition 


Calling Sequences 
F = FORTRAN IV 
M = MAP 
C = COBOL 


Valid Argument Range 


Error 
Code 


Options 


If Argument 
Range Is 


Then The 
Answer Is 


tangent/cotangent 
FTNC (cont.) 


y = cot(x) 
(x expressed 
in radians) 


F: y = COTAN(x) 
M: CALL COTAN(x) 
C: CALL '.CCOTN' 
USING y,x. 


lxl<^2 20 and x may not 
be a multiple of it 
(see note 1) 


73 


lxl^2 20 





74 


x=K7r where k 
is an integer 


Q 


arctangent FATN 


y = arctan(x) 
(y expressed 
in radians) 


F: y = ATANfx) 
M: CALL ATAN(x) 
C: CALL '.CATAN' 
USING y,x. 


any argument 


inappli- 
cable 


inapplicable 


inapplicable 


y = arctan(xi/x2) 

(y expressed 
in radians) 


F: y = ATAN2(xi,x 2 ) 
M: CALL ATAN2(xi,x 2 ) 
C: CALL '.CATN2' 
USING y, xi, x 2 . 


(x,, *M(0, 0) 


11 


(xi,X 2 ) = (0,0) 





arcsine/arccosine 
FASC 


y = arcsine(x) 
(y expressed 
in radians) 


F: y = ARSIN(x) 
M: CALL ARSIN(x) 
C: CALL '.CARSN' 
USING y,x. 


lxl<l 


72 


lxl>l 





y = arccosine(x) 

(y expressed 
in radians) 


F: y = ARCOS(x) 
M: CALL ARCOS(x) 
C: CALL '.CARCS* 
USING y,x. 


lxl<l 


72 


lxl>l 





hyperbolic 

sine/cosine FSCH 


y = ke*-e-*) 


F: y = SINH(x) 
M: CALL SINH(x) 
C: CALL '.CSINU' 
USING y,x. 


1x1^88.029692 


75 


lxl> 88.029692 


Q 


y = He x +e-*) 


F: y = COSH(x) 
M: CALL COSH(x) 

C: call '.ccosh; 

USING y,x. 


1x1^88.029692 


75 


lxl> 88.029692 


fi 


hyperbolic 
tangent FTNH 


e x -e~ x 
y e* ■+ e - * 


F: y = TANH(x) 
M: CALL TANH(x) 
C: CALL '.CTANH' 
USING y,x. 


any argument 


inappli- 
cable 


inapplicable 


inapplicable 


error function FERF 


2 f * * 


F: y = ERF(x) 
M: CALL ERF(x) 
C: CALL '.CERF' 
USING y, x. 


any argument 


inappli- 
cable 


inapplicable 


inapplicable 


gamma/loggamma 
FGAM 




F: y = GAMMA(x) 
M: CALL GAMMA(x) 
C: CALL '.CGAMA' 
USING y,x. 


2 _127 <x<34.843 


76 


x^2" 127 
or 
x^34.843 


Q 


log base e of 
above 


F: y = ALGAMMA(x) 
M: CALL ALGAMMA(x) 
C: CALL '.CALGM' 
USING y, x. 


0<x<2.0593xl0 3e 


77 


x<0 
or 
x^2.0593xl0 86 


n 



Note: For more details on the valid argument ranges for the tangent/cotangent subroutine and how these ranges can be expanded or reduced 
through the FMTN subroutine, see "Error Control Modification for the FTNC Subroutine— FMTN." 

Figure 25A. Single-Precision Subroutines in the FORTRAN IV Mathematics Library ( cont. ) 
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Subroutine Name 


Definition 


Calling Sequences 
F = FORTRAN IV 
M = MAP 
C = COBOL 


Valid Argument Range 


Error 
Code 


Options 


If Argument 
Range Is 


Then The 
Answer Is 


square root FDSQ 


y = x s 


F: y = DSQRT(x) 
M: CALL DSQRT(x) 
C: CALL '.CDSQR' 
USING y, x. 


O^x 


22 


x<0 


lx. J 


exponential FDXP 


y = e x 


F: y=DEXP(x) 
M: CALL DEXP(x) 
C: CALL '.CDEXP' 
USING y,x. 


x<88.029692 


19 


x> 88.029692 


fi 


exponentiation 

floating-point base 
and fixed-point 
exponent FDXl 


_ i 
y-x 


F: y = x**i 

M: CALL .DXP1. (x, i) 
C: CALL '.CDXPT 
USING y, x, i. 


x^=0 


14 


x = 

;=o 





15 


x = 

f<o 





exponentiation 

floating-point base 
and floating-point 
exponent FDX2 


y = x" 


F: y = x**a 

M: CALL .DXP2. (x, a) 
C: CALL '.CDXP2' 
USINGy,x,a. 


x>0 


16 


x<0 

a^O 


Ixl* 


17 


x = 
a = 





18 


x = 
a<0 





logarithm FDLG 


y = log e (x) 


F: y = DLOG(x) 
M: CALL DLOG(x) 
C: CALL '.CDLOG' 
USING y,x. 


0<x 


20 


X := u 


_o 


21 


x<0 


log e Ixl 


y = logio (x) 


F: y = DLOG10(x) 
M: CALL DLOGlO(x) 
C: CALL '.CDL10' 
USING y,x. 


0<x 


20 


x = 


-Q 


21 


x<0 


logio Ixl 


sine/cosine FDSC 


y = sine(x) 

(x expressed 
in radians) 


F: y = DSIN(x) 
M: CALL DSIN(x) 
C: CALL '.CDSIN' 
USING y,x. 


lxl<2 50 7T 


23 


lxl^2 5 °7T 





y = cosine(x) 

(x expressed 
in radians) 


F: y = DCOS(x) 
M: CALL DCOS(x) 
C: CALL '.CDCOS' 
USING y, x. 


lxl<2 50 7T 


23 


lxl^2 5 °7T 





arctangent FDAT 


y = Arctan(x) 
(y expressed 
in radians) 


F: y=DATAN(x) 
M: CALL DATAN(x) 
C: CALL '.CDATN' 
USING y,x. 


any argument 


inappli- 
cable 


inapplicable 


inapplicable 


y = arcfan(xi/x2) 

(y expressed 
in radians) 


F: y = DATAN2(xi,x 2 ) 
M: CALL DATAN2 

(X1,X2) 

C: CALL '.CDAT2' 
USING y,xi,x 2 . 


(x,,x*)^(0,0) 


24 


(x,,x 2 ) = (0,0) 





Modular 

arithmetic— FDMD 


see note 

i 


F: y = DMOD(b,d) 
M: CALL DMOD (b,d) 
C: CALL '.CDMOD' 
USING yh r d. 


any argument 

1 


inappli- 
cable 


inapplicable 

i 


inapplicable 

I 



Note: B modulo D is defined as B— [B/D] *D. The brackets indicate that only the integer portion of the expression within them is used in evaluati 
the equation. 

Figure 25B. Double-Precision Subroutines in the FORTRAN IV Mathematics Library 
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Subroutine Name 


Definition 
Notation: 

Z = Xi + 1X2 


Calling Sequences 
F = FORTRAN IV 
M = MAP 
C = COBOL 


Valid Argument Range 


Error 
Code 


Options 


If Argument 
Range Is 


Then The 
Answer Is 


square root FCSQ 


1 

real y^O 


F: y = CSQRT(z) 
M: CALL CSQRT(z) 
C: CALL '.CCSQR' 
USING y,z. 


any argument 
(see note 1) 


inappli- 
cable 


inapplicable 


inapplicable 


exponential FCXP 


y = e* 


F: y = CEXP(z) 
M: CALL CEXP(z) 

/- rAii ' rrcYD 1 

USING y,z. 


x.^88.029692 


26 


X!> 88.029692 


fi[cos(x 2 ) + 
isin(x 2 )] 


lx 2 l<2 23 


27 


lx 2 l^2 25 


+ 0i 


exponentiation 

complex base and 
fixed-point exponent 
FDXl 


y = z l 


F: y = z**i 
M: CALL .CXP1, (z,i) 
C: CALL '.CCXPT 
USING y,z,\. 


z^0 + 0i 


14 


z = + 0i 

;=o 





15 


z=o+o; 
;<o 





logarithm FCLG 


y = PVIog e (z) 
/ t„ o^ 


F: y = CLOG(z) 
M: CALL CLOG(z) 
C: CALL '.CCLOG' 
USING y,z. 


z^0 + 0i 
(see note 1) 


28 


z=o+o; 


-fi+o; 


sine/cosine FCSC 


y = sin(z) 


F: y = CSlN(z) 
M: CALL CSIN(z) 
C: CALL '.CCSIN' 
USING y,z. 


lx 1 l<2 2S 


29 


lx,l^2 25 


+ 0i 


lx 2 l^88.029692 


30 


ix 2 l> 88.029692 


(see note 3) 


y = cos(z) 


F: y = CCOS(z) 
M: CALL CCOS(z) 
C: CALL '.CCCOS' 
USING y,z. 


lx 1 l<2 2S 


29 


lx,l^2 25 


o+o; 


1x21^88.029692 


30 


Ix2l>88.029692 


(see note 3) 


absolute value FCAB 


y = lzl 


F: y = CABS(z) 
M: CALL CABS(z) 
C: CALL '.CCABS' 
USING y,z. 


any argument 
(see note 1 ) 


inappli- 
cable 


inapplicable 


inapplicable 


arithmetic FCAS 


y = zi X z 2 


F: y = zi* z 2 
M: CALL .CFMP.(z,,Z2) 
C: CALL '.CCFMP' 
USING y,xi,x 2 . 


any argument 
(see note 1) 


inappli- 
cable 


inapplicable 


inapplicable 


y = zi-rza 


F: y = zi/z 2 
M: CALL .CFPD.(zi,z 2 ) 
C: CALL '.CCFDP' 
USING y,xi,x 2 . 


any argument 
(see note 1) 


inappli- 
cable 


inapplicable 


inapplicable 



Note 1: Floating-point overflow can occur. 

Note 2: PV = principal value. The answer given will be from that branch where the imaginary part lies between -w and v. More specifically, -7r<y 2 ^7r 

unless xi<0 and x 2 = —0, in which case y 2 = — ir. 
Note 3: The optional answers for complex sine/cosine are as follows: 



> 88.029692 



<- 88.029692 



— [sin(xi) + icos(xi)] 



— [sin(xi) - icos(xi)] 



— [cos(xi) — isin(xi)] 



— [cos(xi) + isin(xi)] 



Figure 25C. Complex Subroutines in the FORTRAN IV Mathematics Library 
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Subroutine Name 


Definition 


Calling Sequences 
F = FORTRAN IV 
M = MAP 
C = COBOL 


Valid Argument Range 


Error 
Code 


Options 


If Argument 
Range Is 


Then The 
Answer Is 


double precision 
floating-point trap 
routine (7094 
library only) 
.FPTRP 


floating-point 
trap subroutine 


entered only via trap 


inapplicable 


inappli- 
cable 


inapplicable 


inapplicable 


FMTN 

(see note 1) 


resets accuracy 
guarantee for 
single-precision 
tangent 
subroutine 


F: CALL MTAN(fc) 
M: CALL MTAN(fc) 
C: (not available) 


O^it 

where k is an integer 


inappli- 
cable 


inapplicable 


inapplicable 


double-precision 

arithmetic simulator 
FDAS 


performs double- 
precision 
addition, 
multiplication, 
and division 
on a 7090. 


F: not available 
M: (see note 2) 
C: not available 


any argument 


inappli- 
cable 


inapplicable 


inapplicable 



Note 1: A detailed description of the FMTN subroutine is in "Error Control Modification for the FTNC Subroutine - FMTN." 
Note 2: The MAP language calling sequences are described under "7090 Double-Precision Arithmetic Simulator - FDAS." 

Figure 26. Miscellaneous Subroutines in the FORTRAN IV Mathematics Library 



FORTRAN //ti/.tw /.A^rw 
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This section describes the Fortran utility subroutines 

for testing machine indicators and recording the status 

of the console and selected portions of core storage. 

Other Fortran utility subroutines are described in the 

section "Subroutine Library Information." 

Machine Indicator Test Subroutines 

The following subroutines are referred to by call 
statements in the Fortran iv language. In the descrip- 
tions of the subroutines an I is used to specify any 
integer expression, and a J is used to specify any 
integer variable. 

FSLITE Subroutine 

The fslite subroutine is used to test sense lights. The 
source program statements are: 

CALL SLITE(I) 
If I = 0, all sense lights are set off. If I = 1, 2, 3, or 4, 
the corresponding sense light is set on. 

CALL SLITET(IJ) 
Sense light I ( 1, 2, 3, or 4) is tested and set off. If the 
sense light is on, the variable J is set to 1; if it was 
off, J is set to 2. 

FSSWTH Subroutine 

The fsswth subroutine is used to test sense switches. 
The source program statement is: 

CALL SSWTCH(IJ) 
Sense switch I ( 1, 2, 3, 4, 5, or 6) is tested. If the sense 
switch was off, J is set to 1; if it was on, J is set to 2. 



FQVERF Subroutine 

The foverf subroutine is used to test the Overflow 
Indicator. The source program statement is: 

CALL OVERFL(J) 
If an overflow condition exists, the variable J is set to 1; 
if a nonoverflow condition exists, J is set to 2. The 
machine is always left in a nonoverflow condition after 
execution. 

FDVCHK Subroutine 

The fdvchk subroutine is used to test the Divide Check 
Indicator. The source program statement is: 

CALL DVCHK(J) 
If the divide check indicator was on, the variable J is 
set to 1; if it was off, J is set to 2. The divide check 
indicator is always left in off status after execution. 

Dump Subroutine 

The fdmp subroutine records select portions of core 
storage on the system output unit. Either of two entry 
points, dump or pdump, is specified, followed by the 
limits of the dump and the dump format. 

dump is the entry point for a dump of the object 
program. Upon completion of the dump, the contents 
of core storage are restored and control is returned to 
.lxcon, the postexecution subroutine. 

pdump is the entry point for a snapshot dump of 
selected portions of core storage. After the dump has 
been taken, the contents of core storage are restored, 
control is returned to the object program, and execu- 
tion of the program continues. 
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FORTRAN 










Logical 


System 








Unit 


File 


Mode 


Function 






Standard 


Alternate 








Package 


Package 




01 


SYSUT1 


Binary 


Binary or BCD 


Input or output 


02 


SYSUT2 


Binary 


Binary or BCD 


Input or output 


03 


SYSUT3 


Binary 


Binary or BCD 


Input or output 


04 


SYSUT4 


Binary 


Binary or BCD 


Input or output 


05 


SYSIN1 


BCD 


BCD 


Input 


06 


SYSOU1 


BCD 


BCD 


Output 


07 


SYSPP1 


Binary 


Binary 


Output 


08 


System 

Availability 

Chain 


BCD 


BCD 


input or output 



Figure 27. Correspondence Between FORTRAN Logical Units and System Files 



The dump subroutine can be used in a Fortran iv 

program, a map program, or a cobol program. The 

following call statements are used in both Fortran iv 

and map programs: 

CALL DUMP ( Ai,Bi,Fi, , Ai,Bi,Fi ) 

CALL PDUMP ( Ai,Bi,Fi, .... , Ai,Bi,Fi ) 

where A and B, which are symbolic addresses, specify 
the limits of the area to be dumped. 

F indicates the dump format and can be one of the 
following integers: 

octal dump 

1 floating-point dump 

2 integer dump 

3 octal dump with mnemonics 

After entering linkage mode, the following state- 
ments can be used in a cobol program to call the dump 
subroutine: 
CALL 'DUMP' USING data-name-1, data-name-2 5 

numeric-literal-1 [, data-name-3, 

data-name-4, numeric-literal-2, ] 

CALL 'PDUMP' USING da'ta-name-1, data-name-2, 

numeric-literal-1 [, data-name-3, 
data-name-4, numeric-literal-2, . . . ] 

The data-names represent any working storage areas 
or constants. If the data-name is a file-name, the file 
control block for that file is written on the system out- 
put unit. 

The numerical literals are integers that specify the 
format of the dump. The integers and the correspond- 
ing dump formats are the same as those for a Fortran 
iv or map program. 

If an integer for the format is not given when this 
subroutine is used, the dump format is octal. If no 
limits are specified following the entry point and if the 
format is not specified, all of core storage is dumped 
in octal. 



FORTRAN Files 

The input/output devices used in data transmission 
are always referred to symbolically in Fortran iv pro- 
grams. Symbolic references may be made to a constant 
Fortran logical unit or to a variable unit in the stand- 



ard Fortran input/output package as well as the al- 
ternate package. 

Constant Units 

Any Fortran iv source program input/output state- 
ment that refers to a constant unit (for example, 
read(1, 10) A, where the reference is to the constant 
Fortran logical unit 01 ) causes the library file routine 
corresponding to that unit to be loaded with the object 
program. A file routine contains a map language file 
pseudo-operation that determines various file specifica- 
tions, such as unit assignment, block size, and file type. 
The unit assignment specification establishes corre- 
spondence between Fortran logical units and symbolic 
units. See Figure 27. 

If additional logical units are desired, a file routine, 
in the following format, must be inserted into the 
user's program: 



.UNxx. 
UNITxx 



ENTRY 

PZE 

FILE 



.UNxx. 

UNITxx 

Specifications 



Wnere xx is a two-uigii Fortran i.ogicai unit number. 

If the additional logical units are to be permanent, 
a file routine must be inserted in the Subroutine Li- 
brary and an entry must be made in the table that 
describes these routines in the fvio subroutines. 

Variable Units 

Any Fortran iv source program input/output state- 
ment that refers to a variable unit causes the fvio sub- 
routine (.fvio in the alternate input/output package) 
and all file routines to be loaded with the object pro- 
gram. The following is an example of such an input/ 
output statement: 

WRITE (1, 10) A 
In this example, the Fortran input/output logical 
unit I varies during execution of the program. The 
fvio subroutine (or .fvio) takes the value of the 
variable unit at the time the variable input/output 
statement is to be executed, and refers to a table to de- 
termine which file routine is required. 
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Programming in Sections 



Under the ibjob Processor system a programmer can 
submit jobs divided into sections. Each individual sec- 
tion can be in map, Fortran, cobol, or relocatable 
binary, ibjob can thus process sections in different lan- 
guages in the same job. This flexibility has useful con- 
sequences: 

1. Programmers can use the best features of each 
language. For example, the flexibility in the control and 
manipulation of data under the map language can be 
combined with the simplicity of Fortran mathematical 
capabilities. 

2. Sections of a large job can be coded and tested by 
different programmers at different times, and then 
combined. 

3. Jobs that have already been tested can be saved 
in relocatable binary card form for later combination 
with other sections, thus reducing compile and assem- 
bly time. 

Examples of Programming in Sections 

Configurations that can be used in multilanguage pro- 
gramming are shown in Figures 28, 29, and 30. Note 
that any one of the decks shown in these examples can 



be replaced by its relocatable binary equivalent (see 
"Relocatable Binary Decks"). 

Note: If the entry point to a called cobol program 
section is defined — as in Figure 28 - by the deckname 
of the cobol section, the call to the cobol section 
cannot include parameters and return must be made 
through the stop run verb (see a description of the 
stop run verb in the cobol manual). But if the entry 
point is defined — as in Figure 29 — by the entry point 
clause of the enter verb, return to the calling deck is 
by the return clause of the enter verb. The latter 
method of definition is preferable. 

Grouping FORTRAN Source Decks 

To make the best use of the new Fortran iv Compiler 
speed, the programmer should group all Fortran 
source decks together in a multilanguage program. 

COBOL-FORTRAN Program Adjustments 

Programmers who wish to use cobol and Fortran 
decks in the same program should be aware that they 
may encounter some problems. For example, Fortran 
and cobol references to multidimensional arrays are 
made on a different basis. 



1 8 


16 


SJOB 


WAP MAIN PROGRAM CALLING FORTRAN SUBROUTINE 


$EXECUTE 


IBJOB 


$IBJ0B 


MAP 


$IBMAP MAPI 


N0DECK.M94 


NAP1A SAVE 





CALL FTC1A(P1,P2) 



RETURN MAP1A 

END 
$*F0LL0WING IS A FORTRAN SUBROUTINE CALLING A COBCL SUBROUTINE 
$IBFTC FTC1 N0DECK,M94,XR7 
SUBROUTINE FTCIA(A.B) 



CALL CBC1 



RETURN 

END 
$*F0LL0WING IS A COBOL SUBROUTINE WITH AN 
$*ENTRY POINT THROUGH THE DECKNAME 
$IBCBC CBC1 N0DECK,XR7 



STOP RUN. 
$CBEND 

(END-OF-FILE CARD) 
$ST0P 



Figure 28. MAP Main Program Calling FORTRAN Subroutine 
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1 8 
$JOB 

$EXECUTE 
$IBJOB 



16 

FORTRAN MAIN PROGRAM CALLING MAP, COBOL 

IBJOB 

MAP 



$IBFTC MAIN N0DECK,M94,XR7 



CALL MAP1A(A,B) 



CALL CBCIA(C.D) 



STOP 

END 
jxcni i Q^jfijQ IS A MAP SUBROUTINE CALLING A CutJUL SUBkuU' INE 
$IBMAP MAPI N0DECK,M94,XR7 
MAP1A SAVE 

CLA* 3,4 (PICK UP MAIN PROGRAM ARGUMENT A) 



SXA SVXR4.4 
CALL CBC1A(E,F) 
SVXR4 AXT **,4 (RESTORE XR4) 



STO* 4,4 
RETURN MAP1A 



(STORE IN MAIN PROGRAM ARGUMENT B) 



$*FOLLOWING IS A COBOL SUBROUTINE WITH ENTRY POINT DEFINED BY 

$*ENTRY POINT CLAUSE 

$IBCBC CBC1 N0DECK,M94,XR4 



PI. ENTER LINKAGE-MODE. 

ENTRY POINT IS 'CBCIA' 

RECEIVE FACTOR 

PROVIDE RESULT. 
P2. ENTER COBOL. 



P3. ENTER LINKAGE-MODE. 
RETURN VIA 'CBCIA'. 
P4. ENTER COBOL. 



STOP RUN. 
$CBEND 
(END-OF-FILE CARD) 



Figure 29. FORTRAN Main Program Calling MAP and COBOL Subroutines, and MAP 
Subroutine Calling COBOL Subroutine 



Another problem occurs when a cobol deck and a 
fortban deck refer to the same physical input unit. In 
such a case, the iocs look-ahead buffering feature could 
disrupt the sequence of information read in. The pro- 
grammer can avoid the problem by placing the data 
referred to by each deck on a separate physical unit. 



Where cobol and Fortran decks in a program refer 
to the same physical output unit and the order of the 
data written on the file is not important, the pro- 
grammer can ignore the problem. If the cobol file is 
closed first, however, it should be closed with no 
rewind. 
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1 8 16 

$JOB COBOL MAIN PROGRAM CALLING FORTRAN, MAP 

$EXECUTE IBJOB 

$IBJOB MAP 

$IBCBC COBOL1 LIST 



PI. ENTER LINKAGE-MODE. 

CALL 'FTC1A' USING ADDEND, SUM. 

CALL 'MAP1A' USING TAX, DISCOUNT, 

RETURNING ERROR-RETURN. 
P2. ENTER COBOL. 



ERROR-RETURN 



STOP RUN. 
SIBFTC FTC1 LIST 

SUBROUTINE FTC1A(A,B) 



RETURN 

END 
$IBMAP MAPI LIST 
f"iAPlA SAVE E 

CLA* 3,4 (PICK UP FIRST ARGUMENT) 



STO* 4,4 (STORE IN SECOND ARGUMENT) 
RETURN MAP1A.1 (ERROR RETURN) 



RETURN MAP1A (NORMAL RETURN) 

iSTOP 
(END-OF-FILE CARD) 

Figure 30. COBOL Main Program Calling FORTRAN and 
MAP Subroutines 
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PART 2: SYSTEM PROGRAMMER'S INFORMATION 



Processor Monitor Information 



The Processor Monitor provides a common operating 
environment for the ibjob language translators. It 
supervises loading of the ibjob components and regu- 
lates the compiling, assembling, loading, and executing 
of a job. The Monitor consists of three parts: job con- 
trol, process control, and the input/output editor. 
Figure 31 shows the relationships among job control, 
process control, and the other components in the ibjob 
Processor system. 

Job control is called into storage by the ibsys Moni- 
tor when a sexecute card specifying ibjob is en- 
countered in a source program. It directs the over-all 
processing of a job; it calls process control into storage 
to supervise the assembly of a source program into 
binary form for the Loader; it calls the Loader to load 
the assembled program and to start its execution. 
Process control returns to job control at the end of the 
assembly process. The Loader returns when a job 
cannot be executed. When assembly errors are serious 
enough to halt processing or a program cannot be 
executed, job control returns to the ibsys Monitor. 



After execution the object program returns directly 
to the ibsys Monitor, because the Loader has almost 
entirely overlaid the ibjob Monitor with the object 
program. Usually, the ibsys Monitor then reads the 
input file to determine the requirements of the next job. 
But if load-time debugging is requested for the pro- 
gram just executed, the ibsys Monitor calls job control 
back into storage. Job control calls in process control to 
initiate processing of the debugging information ob- 
tained during execution of the program. 

Process control supervises the assembly of a source 
program by calling into storage the Load-Time De- 
bugging compiler, the Assembler, the cobol Compiler, 
or the Fortran Compiler, as they are required to trans- 
late the different types of decks. It also calls in the 
debugging postprocessor routines after a program has 
been executed for which load-time debugging is re- 
quested. After the debugging listings are written on 
the output tape, control returns to process control, 
which looks for the next sexecute card on the output 
file. If this card specifies ibjob, process control proceeds 
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Figure 31. Relationship among Job Control, Process Control, and other IBJOB Components 
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as usual to supervise the assembly of the next program. 
If ibjob is not requested, process control returns to the 
ibsys Monitor. 

The input/output editor is called into storage with 
process control, which uses it to regulate the actions 
of the Input/Output Executor whenever any Processor 
input/output functions are to be performed. 

The following is an example of how the three sections 
of the Monitor control the flow of processing for a 
typical program: 

PROGRAM PROCESSOR ACTIONS 

$IBSYS 

$JOB 

$EXECUTE IBJOB The IBSYS Monitor calls job con- 

trol into storage. Job control calls 
process control into storage. 

$IBJOB MAP, Process control initializes the input/ 

LOGIC output editor and uses it to read 

the $IBJOB card. It scans options, 
opens the load file for the Assem- 
bler and FOBTRAN Compiler out- 
put to the Loader, and uses the 
input/output editor to read the 
next card on the input file. 

$IBMAP NODECK, Process control calls the Assembler 

M94 into storage. 

( MAP deck with CALL The Assembler uses the input/out- 

DUMP as last step ) put editor to read the MAP deck 

from the input file, then translates 

the deck into binary form for 

Loader processing. During assembly 

the input/output editor writes the 

Assembler output on the load file 

for Loader processing and on the 

output file for printed listings. The 

Assembler returns control to process 

control, which uses the input/output 

editor to read the next card on the 

Process control input file. 

$IBFTC NODECK, Process control calls the FORTRAN 

M94 Compiler into storage. 

( FORTRAN deck called The FORTRAN Compiler uses the 
by MAP deck ) input/output editor to read the 

FORTRAN deck from the input 
file. The Compiler assembles the 
deck into binary form for Loader 
processing. During assembly the 
input/output editor writes the 
Compiler output on the load and 
output files. The Compiler returns 
control to process control. Process 
Control uses the input/output edi- 
tor to read the next card on the 
input file. 
( end-of -file-card ) Process control returns control to 

job control, indicating the program 
can be loaded. Job control trans- 
fers control to the Loader, which 
loads the program. The Loader 
uses the input/output editor to read 
the load file and to write the core 
storage map and cross-reference 
table on the output file. The Loader 
overlays all of the IBJOB Monitor 
with the object program except for 
a few saved communication words. 



PROGRAM 



PROCESSOR ACTIONS 

It transfers control to the object 
program, which executes. The dump 
routine called by the program 
writes the dumped information on 
the output file. The program post- 
execution routine returns control to 
the IBSYS Monitor. 



$IBSYS 
$STOP 



Job Control Operations 

Job control contains routines to determine whether it 
should call process control or the Loader into storage. 
It also contains an action routine that can call the 
ibjob system components into storage. 

When job control receives control from the ibsys 
Monitor, it reads the system units position table into 
the ibjob communication area ( See Appendix C, "ibjob 
Communication Area" ) and then uses the table to call 
process control into storage. The system units position 
table lists the position of each record on the symbolic 
input/output unit ( usually syslbi ) on which the ibjob 
system programs are stored. 

When a source program has been assembled, process 
control transmits a word to job control. By testing this 
word, job control determines whether processing 
should be continued by calling the Loader into storage, 
or whether it should be halted by transferring control 
to the ibsys Monitor through location sysret in the 
ibsys nucleus. If the program cannot be executed after 
it is loaded, the Loader returns control to job control, 
which returns to sysret. 

ACTION Routine for Calling IBJOB Components 

The action routine is used by both job control and 
process control to locate ibjob components on the sys- 
tem library file and to read them into storage when they 
are needed. The routine can be used to position the 
system library to a particular system record or to posi- 
tion to and read one or more system records. It is not 
necessary for the calling program to know the order or 
format of the records on the system library. All that 
the calling program need supply to the action routine 
is the label of the required action. The action routine 
consults three tables and performs the desired action. 
These tables are the action table, the action list, and 
the system unit position table. 

The action table is used to identify the action label 
supplied by the calling program. Each entry consists 
of two words, the first of which is: 
BCI I, label 

where label is a six-character alphameric name of the 
required action. The second word is either 

PZE a 
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where a is the location of the action list, or 
pfx n 

where the second word is the action list itself, pfx is 
either mze or mon, and n is an entry in the system unit 
position table. In this case, the action list is limited to 
one word. 

The action list may consist of any number of one- 
word entries, the last of which must have a negative 
prefix code. Each word is of the form: 

pfx n 
where n is again an entry in the unit position table and 
pfx is one of the following: 

1. pze or mze, which causes the system unit to be 
positioned as indicated. 

2. pon or mon, which causes the system unit to be 
positioned as indicated and the record at that position 
to be read. 

The unit position table consists of a one-word entry 
for each standard record on the input/output unit(s) 
where the ibjob system is stored. An entry is designated 
by the n portion of an action list entry. The unit posi- 
tion table can have either of two formats, depending 
on whether the system is on one or more than one 
magnetic tape unit, or on disk storage. 

When tape is being used, the format for an entry is: 

pfx rccnt, , flcnt 

where pfx is the library tape number on which the 
record exists and where rccnt and flcnt indicate the 
position of the record on that unit. Flcnt is the number 
representing the file position of a particular component. 
Rccnt is the number representing the record position 
within the component file. 

If pfx is pon, indicating system library unit 1 ( syslbi ) , 
the file position is relative to the position of the first 
ibjob Processor file. When job control reads this rela- 
tive position table into core storage for process control 
use, it also converts the flcnt part of each entry to an 
actual file position. The actual file position is the num- 
ber of files between the load point and the system 
component involved. If pfx is other than pon, flcnt is 
already the actual file position. 

When the system is stored on disk or drum, the unit 
position table is automatically converted to a track posi- 
tion table. The decrement portion of each entry con- 
tains the starting track address of the address of the 
record. These track addresses are obtained by scanning 
the table of record names and track addresses contained 
in the ibsys Supervisor. 

System Record Format 

Each standard system record is preceded by the fol- 
lowing sequence: 

IOCP SYSFAZ, , 1 
BCI 1, recnm 



This is followed by a command to read a transfer to 
an entry point into the appropriate transfer location 
in job control or the component involved. 

The rest of the record is scatter-loaded, each section 
being preceded by the proper iocx command, the last 
of which must be ioct. 

P repositioning Feature 

The action routines in the Processor Monitor are also 
used to preposition a system library unit when possible. 
If the system is assembled for disk, drum, or Hypertape, 
the prepositioning feature is inoperative. 

Using One Library Unit: If the ibjob Processor is 
stored on an ibm 729 Magnetic Tape Unit, the preposi- 
tioning feature performs the following actions: 

ibjob Processor components are stored on a system 
library tape in the following order: Monitor, Load- 
Time Debugging compiler, cobol Compiler, Assembler, 
Loader, and Library. The Assembler is read into core 
storage in two stages. After the last record of the As- 
sembler is read in, the next control card is read. If this 
control card is a $ibftc, $ibcbc, or sibmap card, a back- 
space file operation is performed. If the next control 
card is not one of these three cards, no action is per- 
formed. 

If the ibjob Processor is stored on either an ibm 729 
Magnetic Tape Unit or an ibm 7340 Hypertape Drive, 
the system tape is rewound after the last record of the 
Loader has been read into core storage. 

yj sing jyxtiwipLe L-iiorG,ry L^ntvs: lwo uiilerenc config- 
urations are possible when multiple library units are 
used to store the ibjob Processor system programs. 
Either two ibm 729 Magnetic Tape Units can be used; 
or one tape unit can be used for the Subroutine Library, 
with the rest of the Processor system on disk or drum 
storage. 

The configuration of two tape units makes full use 
of the prepositioning feature. Both units must, how- 
ever, be on the same channel and all records of a com- 
ponent of the ibjob Processor must be on the same tape. 
If more than two units are used, the prepositioning 
feature applies only to the unit that contains the 
Processor Monitor. Any other units are not rewound 
but only positioned when a record is required. 

After the last record of the Assembler is read into 
core storage, the next control card is read. If this con- 
trol card is a sibftc, sibcbc, or $ibmap card, a backspace 
file operation is performed for the tape that contains 
the Processor Monitor. The other system tape is re- 
wound. The backspace file operation is not begun if 
neither of the compilers nor the Assembler is on the 
tape that contains the Processor Monitor. 

After the last record of the Loader has been read into 
core storage, both system tapes are rewound. 
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The configuration using tape with drum or disk stor- 
age requires that only the files for the Library be on 
tape. The tape for the Library must be on an ibm 729 
Magnetic Tape Unit. After the last record of the Loader 
has been read into core storage, the Library tape is 
rewound. 



Process Control Operations 

Process control contains routines to initialize the input/ 
output editor and direct its operations. It also contains 
routines for controlling the assembly of a source pro- 
gram and for calling the load-time debugging post- 
processors. It uses a control card search routine mainly 
to determine which component must be called into 
storage during the assembly process and to obtain in- 
formation for the input/output editor. It uses an option 
scan routine to record job specifications for use by 
the other ibjob components, and it uses an error pro- 
cedure routine after each component has assembled 
a deck, to evaluate the effect of program or machine 
errors on future processing. Process control uses the 
action routine in job control to read the components 
into storage. 

Initialization of the Input/Output Editor 

After being called by job control, process control scans 
the system unit function table in the ibsys nucleus to 
make sure that the necessary input/output units have 
been assigned to Processor functions. It then attaches 
and opens the files it will use and initializes the input/ 
output editor. 

Process control initializes the input/output editor 
by supplying to it through the entry point ioedit the 
locations of the file control blocks for the input/output 
units that will be used during processing and the loca- 
tion of the Monitor communication word comcel. 
Certain bits in comcel are used to store information 
for the input/output editor. Process control opens and 
closes all input/output editor files and positions them 
when necessary. All file control blocks used by the 
input/output editor are located in process control. 
Process control and the input/output editor normally 
use system units for the following purposes : 

System Library Unit (SYSLB1): This is the storage 
unit for the ibjob Processor. The system may also be 
stored on several units. In this case, alternate units, such 
as syslb2, syslb3, and syslb4, would also be used. 

System Input Unit (SYSIN1): This is used for the 
ibjob Processor input. Alternate units may also be used 
if required. 

System Output Unit (SYSOU1): This is used for the 
ibjob Processor listing output. Alternate units may also 
be used if required. 



System Peripheral Punch (SYSPP1): This is used for 
the ibjob Processor punched output. 

System Utility Unit 1 (SYSUT1): This is not used by 
the process control or by the input/output editor. 

System Utility Unit 2 (SYSUT2): This is used for the 
ibjob Processor load file. 

System Utility Unit 3 (SYSUT3): This is not used by 
process control or by the input/output editor. 

System Utility Unit 4 (SYSUT4): This is used for 
cobol compiler output to the Assembler. 

System Alternate Checkpoint Unit (SYSCK2): This 
is used for the debugging file, which contains output 
from the Load-Time Debugging compiler, the Loader, 
and the Load-Time Debugging interpreter routines. It 
is used by the Load-Time Debugging editor and trans- 
lator as the input file. If the system is stored on more 
than one unit, syslb2, syslb3, and syslb4 may also be 
used. Alternate units for input and output can also 
be designated if required. 

Control Card Search 

After initialization of the input/output editor, process 
control starts to search for control cards. The control 
card search routine calls the input/output editor to get 
the next line of input. If the current job is to be loaded, 
any card that contains a dollar sign in column 1 and is 
not recognized as an ibjob Processor control card is 
added to the load file, which is the basic input to the 
Loader. An unrecognized card is ignored if the program 
is not to be loaded. Each recognized card is listed and 
may be printed on-line, and any necessary action, which 
may include a scan for options, is taken. The option 
scan routine is described under "Process Control 
Option Scan." 

Cards without a dollar sign in column 1 are not 
added to the load file. Binary cards that are not within 
an object deck cause an error message to be written. 
Programs that are assembled using the absmod option 
on the sibmap card are not added to the load file. 

$IBJOB Card Action 

The sibjob card must be the first card of every ibjob 
Processor application. Unless either the nosource op- 
tion or the nogo option without a map, logic, or dlogic 
option is specified, process control starts a load file and 
places the sibjob card in it as the first card. Any cards 
that contain a dollar sign in column 1 and that are not 
recognized by process control, as well as any object 
decks and Assembler output, are placed in the load file. 
If the nosource option is present, signifying that there 
is no compilation or assembly in this application, or a 
sibrel card is encountered, signifying that there are 
only object decks from that card on, process control 
returns control to job control. Job control, in turn, calls 
the Loader to load from the system input unit. 



56 



Component Control Card Action 

Cards that signal process control to call other ibjob 
components into storage are listed below. 

$IBDBL Card: When the sibdbl card is encoun- 
tered, process control sets the input/output editor con- 
trols for a debugging compilation and calls the 
compiler section of the Load-Time Debugging Pro- 
cessor. The Load-Time Debugging compiler calls the 
input/output editor for this control card, which must 
immediately precede every debugging request deck. 

$IBFTC Card: Process control sets the input/output 
editor controls for Fortran rv compilation and calls the 
Fortran iv Compiler when the sibftc card is encoun- 
tered. The Fortran iv Compiler calls the input/output 
editor for this control card, which must immediately 
precede every Fortran iv source deck, into storage. 

SIBCBC Card: Process control sets the input/output 
editor controls for a cobol compilation and calls the 
cobol Compiler when the sibcbc card is encountered. 
The cobol Compiler calls the input/output editor to 
read this card. It must immediately precede every 
cobol source deck into storage. Process control auto- 
matically calls the Assembler to assemble cobol Com- 
piler output if the error level permits assembly. 

$IBMAP Card: Process control sets the input/output 
editor controls for a map assembly and calls the As- 
sembler when a sibmap card is encountered. The 
Assembler calls the input/output editor to read this 
control card. It must immediately precede every 
symbolic deck into storage. 

$IBLDR Card: Process control adds the sibldr con- 
trol card and either the object deck following this 
control card, or its complement object deck if an alter- 
nate input unit specified, to the load file if the program 
is to be loaded. If the libe specification is found on the 
sibldr control card, only this card is added to the load 
file, and the alternate input is not sought. A sibldr card 
is the first card in the output deck of the Assembler. 

Optional Control Card Action 

Process control recognizes some control cards that can 
be considered independent of components. Typically, 
these cards control accounting functions or denote 
input/output variations from normal procedure. These 
cards are listed in the following text. 

$ID Card: The $id control card causes process con- 
trol to transfer to the installation accounting routine. 

$IEDIT Card: Process control uses the variable field 
of the siedit control card to set input specifications 
for the application. It may appear at any place in a 
program, and the specifications remain in effect for the 
remainder of the application unless changed by an- 
other siedit card. 

$OEDIT Card: Process control uses the variable field 
of the soedit card to set output specifications for the 



application. It may appear at any place in a program, 
and the specifications remain in effect for the remainder 
of the application unless changed by another soedit 
card. 

$* Card: The s* control card is a comments card, and 
its contents are printed on-line. No other action is taken. 
It may appear in any group of control cards. 

$PAUSE Card: Processing halts when a spause card 
is encountered. The start button must be pressed in 
order to proceed. 

$ENDREEL Card: A reel switch is performed be- 
tween system input units sysini and sysin2 when a 
sendreel card is encountered. This control card must 
be preceded by a file mark. This control card is recog- 
nized only by the input/ output editor and the mini- 
mum, basic, and label levels of iocs. 

$IBREL Card: The sibrel card indicates to the Proc- 
essor Monitor that no more compilations or assemblies 
follow on the system input unit ( sysini ) . 

&TITLE Card: The information contained in columns 
16-72 is placed in the appropriate words of the heading 
buffer. The current date is also placed in the buffer 
unless the nodat option has been specified. The title is 
printed on the text page, and a switch is set to indicate 
that the next Processor or Assembler control card 
should not cause the heading buffer to be reinitialized. 

$DATA or End-of-File Card: Control is transferred 
to the Loader, if loading can be performed, when a 
sdata or end-of-file card is encountered. 

IBSYS Control Card Action 

Control is transferred to the ibsys Monitor when a 
sibsys, sjob, sexecute, or sstop card is read or when 
execution of an object program has been completed. 

Process Control Option Scan 

An option scan may take place if a recognized control 
card has options that can be specified. Process control 
looks for all the options on sibjob, sibldr, siedit, and 
soedit cards and for the absmod option only on sibftc, 
sibcbc, and sibmap cards. Options on sibdbl, sibftc, 
sibcbc, and sibmap cards are scanned only by the com- 
ponent program except for the absmod option on sibftc, 
sibcbc, or sibmap cards. Scanning begins in column 16 
and ends when a blank character is encountered. Each 
set of characters terminated with a comma, or a blank 
in the case of the last set, is treated as an option. The 
option is compared to a dictionary of options and the 
proper action is taken if a matching entry is found. 
Unrecognized specifications are ignored in all cards but 
the siedit and soedit cards. If an unrecognized specifi- 
cation is found on either of these cards, an error mes- 
sage is given. If specifications are not found on a control 
card, the standard option of the installation is assumed. 
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Process Control Error Procedure Routine 

When the Fortran iv Compiler, the cobol Compiler, 
or the Assembler returns control to process control, an 
error word is left in the accumulator. If no error was 
detected by the subsystem, the accumulator address 
and decrement portions contain zero. A suspected 
machine error is indicated by a nonzero decrement, 
and a source program error is indicated by an error 
level number in the address. This error level number 
determines the error procedure used by process con- 
trol: 

LEVEL PROCEDUBE 

1 Allow loading if requested. 

2 Do not allow loading. 

3 or greater Do not allow loading. If the return is from the 

cobol Compiler, do not allow assembly. 

Although the compiler section of the Load-Time De- 
bugging Processor also prints error messages, the errors 
do not prevent loading or execution of the source pro- 
gram. If no source program errors are indicated, a 
machine error indication causes process control to print 
a message on-line specifying the possible operator op- 
tions and then to pause. The options are to retry the 
application, to go on to the next application, or to go 
on to the next job. The operator must specify one of 
the options and press start. If the retry option is 
chosen, the system input, system output, and system 
peripheral punch units are returned to their original 
positions at the beginning of the application and con- 
trol is returned to the control card search routine. No 
alternate input or output units are repositioned by 
process control. 

If a source program error of level 2 or greater is 
indicated, process control does not allow execution of 
the program or retry options, but goes on to the next 
control card, regardless of whether a machine error ac- 
companied the source program error. 

Input/Output Editor Operations 

The input/output editor performs all Processor input/ 
output functions. It provides a line of input or accepts 
punch or listing output upon request. The input/output 
editor writes cobol Compiler output and reads it for 
the Assembler. It also writes the load file and reads it 
for the Loader, but it does not perform intermediate 
input/output operations or on-line printing. 

Process control transfers to the input/output editor 
through the entry point ioedit. All information taken 
from $iedit, *oedit, or $ibjob cards that affect the input/ 
output editor is transmitted through this entry point. 

The input/output editor consist of four sections: 

1. The ioedit utility routine, which initializes and 
controls the other sections. 

2. The input editor, which regulates input to the 
Processor. 



3. The output editor, which regulates all listing out- 
put from the Processor. 

4. The punch editor, which regulates all punched 
output from the Processor. 

IOEDIT Routine 

The ioedit routine uses the information transmitted to 
it by process control to select the proper editor section 
for the job requested. It initializes this section by 
setting flag bits in the required file control blocks, trun- 
cating buffers and releasing them, and transferring con- 
trol to the section. 

Input Editor 

The input editor contains two reading routines that use 
the Input/Output Control System (iocs). The primary 
routine reads only the input file on the system input 
unit ( sysini ) . The secondary one reads an input file on 
an alternate unit. This file may be the Assembler input 
file (output from the cobol Compiler), the load file 
input to the Loader ( Load-Time Debugging compiler, 
Assembler, or Fortran Compiler output, or previously 
assembled binary decks), an input file on an optional 
unit specified on a $iedit card, or an Alter deck that the 
Monitor has moved to the system utility unit ( sysijt2 ) , 
Only one secondary file can be open at a time. Primary 
files and secondary files may consist of bcd card images, 
binary card images, or Prest input, bcd card images 
must be recorded in the bcd mode, 84 characters per 
card image. Binary card images must be recorded in 
binary mode, of 168 characters per card image. The 
last four characters of bcd records and the last eight 
characters of binary records must be standard look- 
ahead bits. These bits are described in the publication 
IBM 7090/7094 IBSYS Operating System, Version 13, 
Operators Guide, Form C28-6355. The input editor 
accepts blocked input of up to ten bcd cards or up to 
five binary cards in each physical record. $-control 
cards must be unblocked. 

After being called by a request for a line of input, the 
input editor determines, from a control location set by 
process control, whether input is to be read from the 
primary file or from the secondary file. It then locates 
the next line and returns control to the calling program, 
leaving the location of this line and its word count in 
the accumulator. To ensure that a line is saved, the 
calling program must move it before requesting an- 
other line. 

If an error condition is sensed, the input editor re- 
turns control to the calling program, sets the sign of the 
accumulator to minus and puts a 1 in its address por- 
tion. If an end-of-file condition is sensed, the input 
editor returns control to the calling program, sets the 
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accumulator to minus and puts a in the address por- transmission is performed through ioedit, the entry 

tion. point to the input/output editor. 

Files used by the input editor are opened, positioned 

if necessary, and closed by process control. Process Output Editor 

control transmits the locations of the file control blocks The third section of the input/output editor is the out- 

to the input editor to allow their initialization. This put editor. It can list on more than one output unit. 
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Normally, the listing file is on the system output unit 
(sysoui ). If an alternate output unit has been specified 
on a soedit card, the output editor places the listing 
output of the Processor Monitor on the system output 
unit, but it uses the alternate output unit for all ibjob 
Processor component listing output until the end of the 
application or until a soedit card specifying the system 
output unit is encountered. 

The output editor keeps page counts and line counts, 
and it ejects pages and inserts page headings when 
necessary. The page headings are given to the output 
editor by process control through ioedit. 

The output editor generates two types of output. The 
contents of the word at location typou determines the 
type of output generated. When location typou is zero, 
the output is in bcd mode, blocked up to five lines per 
block. This output can be printed on the ibm 720 
Printer. When the contents of typou are nonzero, the 
output is in binary mode, blocked up to five lines per 
block. This output can be printed off-line, using the 
ibm 1401 Peripheral Input/Output Program. The first 
word of each output block is a block control word. The 
word contains ( 7600000000xx ) 8 , where xx is the num- 
ber of records (in bcd) contained in the block. The 
first word of each record within the block is a record 
control word. This word contains ( 5xxxxx200460 ) 8 , 
where xxxxx is the number of characters ( in bcd ) con- 
tained in the record. 

A call to the output editor initiates a new line when 
it is requested by the calling sequence and when the 
last line has already been filled. 

Process control opens and closes files used by the 
output editor and transmits the locations of the file 
control blocks to the output editor by means of ioedit. 

Punch Editor 

The punch editor accepts 80-column card images for 
three types of output. Card images may be either col- 
umn binary or bcd, and the three types of output are: 

Punch file 

Load file 

Compiler output file 

All punch editor output files are in binary form, bcd 
card images for the punch file are recorded in column 
binary form, without column binary bits, when they are 
placed in the punch file, bcd card images for the other 
files are inserted in bcd form and are written in binary 
form. Duplicates of the sibjob control cards are 
punched when they are read. 

If the punch editor determines that output is not 
from the cobol Compiler, the card image is placed in 
the punch file. If it is in bcd form, the punch editor 
records it in column binary form, without column 
binary bits. The card is also placed in the load file if 



the proper bit in the control word comcel has been 
set. 

File control blocks for the punch editor files are kept 
in process control. Their locations, along with the loca- 
tion of control flags, are transmitted to the punch editor 
through the entry point ioedit. 
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$DUMP Card 
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tem records to be dumped. The sdump card must be 
inserted in a source program after the sibjob card and 
before the control card calling the component from 
which the dumped information is to be taken. It can- 
not, however, be placed within a particular deck. As an 
example, consider the following sequence of cards: 

$IBJOB 
[insertion point a] 

$IBMAP 

[MAP deck] 
[insertion point b] 

$IBFTC 

[FORTRAN deck] 
A sdump card referring to the Fortran Compiler could 
be inserted at either point a or point b. A card for the 
Assembler, however, can be inserted only at point a. 
The format of a sdump card is: 



6 8 



16 



$DUMP n exxxxx locl/loc2, 1oc3/1oc4, . . 

where n is a digit that designates whether the output is 
to be single-spaced or double-spaced. A 1 in column 6 
designates single-spaced output. Any digit greater than 
1 designates double-spaced output. If this field is omit- 
ted the out n ut is single-spaced. 

The field starting in column 8 contains an alphameric 
character (c) and a five-digit octal number (xxxxx) 
that specifies an absolute location. The alphameric 
character is the sixth character of the name of the sys- 
tem record whose loading causes a dump request to be 
inserted. The dump occurs immediately before the 
instruction at location xxxxx is executed. Location 
xxxxx may, if needed, be outside the system designated 
by character c. (See "Restrictions on Dump Re- 
quests." ) 

The field starting in column 16 contains the limits of 
those portions of core storage to be dumped. Each por- 
tion of core storage is specified by two five-digit octal 
numbers. The lower limit is specified first and is sep- 
arated from the upper limit by a slash. Consecutive sets 
of limits must be separated by commas. The first blank 
encountered in the variable field designates the end of 
the control card. Another sdump card that specifies the 
same system record character and location may be used 
to extend the variable field. The portions of core storage 
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are dumped in the reverse order of their appearance 
on the card. The sdump card specifications are effective 
only during the processing of the source program in 
which they are inserted. 

The first sdump card that is read causes the dump 
routine to be loaded into core storage starting at loca- 
tion 76237 8 . If an accounting routine is in core storage, 
it is overlaid by the dump routine, and locations sysidr 
and syspid in the communications region of the ibsys 
nucleus are reset. The upper core storage limit in loca- 
tion ibjcor in the Processor Monitor communication 
area is set to 76236 8 . 

Restrictions on Dump Requests 

Dump requests have the following restrictions: 

1. Certain system records (ibjob, pump, ibjobb, and 
ibjobc ) are already in core storage when dump requests 
are made. For this reason a sdump card specifying any 
of these records has no effect. A dump request may, 
however, be inserted into any location in core storage, 
including the areas occupied by these records, by using 
the sixth character of a more accessible record name. 
For example, when the system record ibmapj is called 
into core storage, a dump request specifying J 11526 
may be inserted, starting in column 8 on the sdump 
card. Location (11526) 8 is actually in the ibjob system 
record, which is in core storage at the same time as 
ibmapj. In this way information can be dumped during 
the operation of ibjob without actually specifying it. 

If system record ibmapj were called into core storage 
more than once after the sdump card had been read, a 
loop would occur. This is due to the method used for 
inserting dump requests. This method is described in 
item 4. 

2. Dump requests may not be inserted in iocs coding 
or in output editor coding, since the dump routine uses 
both iocs and the output editor for processing output. 
If dump requests are inserted in these areas, a loop 
occurs. 

3. The system records ibldrp and ibldrq cannot be 
dumped, since these records occupy the same area of 
core storage as the dump routine. 

4. sdump requests may not replace tsx instructions 
that are followed by parameters; they may not replace 
instructions that are modified in any way; and they 
may not be inserted where they will appear within 
call psuedo-operation expansions. These restrictions 
are due to the method used for inserting dump re- 
quests. The method is: 

a. The instruction at the location xxxxx s specified 
on the sdump card is saved in a table contained 
in the dump routine. 

b. An instruction to transfer control to the dump 
routine is placed in the specified location. 



c. When the transfer instruction has been ex- 
ecuted, the specified portions of core storage 
are dumped. 

d. The instruction that was saved is placed in the 
following sequence: 



Loc 


instruction 


Loc + 1 


TRA xxxxx + 1 


Loc + 2 


TRA xxxxx + 2 


Loc + 3 


TRA xxxxx + 3 



e. When the dump is completed, control is trans- 
ferred to location Loc. 

$PATCH Card 

The spatch control card is used to insert temporary 
patches in system records, thereby eliminating an un- 
necessary system edit run. The spatch card is inserted 
in a source program in the same position as a sdump 
card. The format of a spatch card is: 

1 8 16 

$PATCH cxxxxx instrl, instr2, . . . 

where the field starting in column 8 contains an alpha- 
meric character (c) and a five-digit octal number 
(xxxxx) that specifies an absolute location. The alpha- 
meric character is the sixth character of the name of the 
system record whose loading causes a patch to be in- 
serted. The patch is inserted starting at location xxxxx 8 . 
Location xxxxx may, if necessary, be outside the system 
designated by cc. (See "Restrictions on Patch Re- 
quests." ) 

The field starting in column 16 contains 12-digit 
octal instructions that are to be loaded into core storage 
starting at location xxxxx 8 . Consecutive instructions 
must be separated by commas. The first blank en- 
countered in the variable field designates the end of the 
control card. Only four octal instructions may be placed 
on one spatch card. 

spatch cards can be used to change or delete instruc- 
tions in a system record. For example, the card: 
$PATCH M23000 076100000000 
changes the instruction at ( 23000 ) 8 in record ibldrm 
to a nop. spatch cards can also be used to add instruc- 
tions. For example, to insert the instruction add 16000 
between the following instructions in ibmapj: 



LOCATION 


OPERATION CODE 


OPERAND 


12000 


CLA 


15000 


12001 


STO 


14000 


se the following 


spatch card sequence: 






INSTRUCTION 


CONTROL CODE LOCATION IDENTIFIER 


IN OCTAL 


SPATCH 


JI2000 


TRA 17000 


$PATCII 


JI7000 


CLA 15000 


$PATCH 


JI7001 


ADD 16000 


$patch 


JI7002 


TRA 12001 



where the locations 17000 through 17002 are available 
for patching purposes. 
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Restrictions on Patch Requests for record ibldrm specifying a location that is actually 

Patch requests have the following restrictions: within iocsb will effectively patch iocsb. 

1. System records ibjob, jdump, iocsb, ibjobb, and 2. System records ibldrp and ibldrq cannot be 

ibjobc cannot be patched directly. They can be patched, since they occupy the same area of core stor- 

patched, however, by using the sixth character of more age as the dump routine, which contains the patch 

accessible record names. For example, a spatch card routines. 
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FORTRAN IV Compiler Information 



The 7090/7094 Fortran iv Compiler ( irftc ) translates 
programs written in the Fortran iv language into 
machine language. The Compiler operates within the 
irsys/ibjob environment and produces text for the 
Loader (ibldr) compatible with that produced by the 
Assembler (ibmap). 

The following important features of the Fortran iv 
Compiler should be noted: 

1. It has its own assembly processor, which elimin- 
ates the need for using the ibmap assembly program. 

2. It is a two-pass system, composed of an instruction 
generation pass (phase A) and an assembly pass 
( phase B ) . 

3. It has a phasing technique for performing multiple 
compilations when a processor application contains a 
program set. (A program set is any group of con- 
secutive Fortran iv source programs as shown in 
Figure 32. Note that a control card other than a $ibftc 
card terminates a program set. ) Phasing permits phase 
A processing for all programs of a program set, fol- 
lowed by phase B processing for all programs of the 
set. When necessary, error message processing for all 
programs of the set is then performed. The Compiler 
is thus read into core storage only once for an entire 
program set. 



Structure of the FORTRAN IV Compiler 

The Compiler is composed of the two processing phases 
A and B and an error message processor. Phases A and 
B are required for each compilation. The message proc- 
essor, which contains all bcd error messages, is read 
into core storage only if an error has been found in one 
or more programs of a program set. If the message 
processor is required, it is called after phase B proc- 
essing of the last program in a program set. 

As a result of this arrangement, the Fortran iv Com- 
piler printout contains the following: 

1. The source programs of a program set. 

2. The storage maps (and assembled program listing 
if requested by the $ibftc control card) in the same 
order as the source programs. 

3. Any diagnostic messages (again, in source pro- 
gram order ) that may be generated. 

Phase A contains the statement scanners for all 
source statements except the data and format state- 
ments. Phase B contains the data and format state- 
ment scanners, the storage allocator routine, and the 
assembly processor routine. The latter two routines 
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provide the output for the storage maps and the list- 
ings, respectively. 

The Fortran iv Compiler may reside on tape, disk, 
or drum storage. Regarded as a tape system, the Com- 
piler consists of three records, containing phase A, 
phase B, and the message processor, respectively. Core 
storage is laid out in accordance with an overlay 
principle. Routines and communication areas that are 
common to all phases remain in the numerically lowest 
part of core storage. Throughout compilation, control 
passes from general routines to particular routines and 
then returns to the general routines at the completion 
of particular-routine processing. Figure 33 shows the 
overall flow of Compiler processing. 

Control among parts of the Compiler is directed by 
the Fortran iv Compiler control routine (fcc). This 



routine passes control first to phase A control, then to 
phase B control, and finally, where relevant, to the 
message processor. Phase A control and phase B con- 
trol direct the activities of their respective phases and 
call the required subprocessors during the time that 
each has control. The subprocessors most frequently 
use the following utility subroutines: the table routine 
(tr), which handles all compiler table activity; the 
bci collector routine, which is used by all statement 
scanners for preliminary preparation of source state- 
ments for translation; the subscript processor, which 
handles subscript combinations; the conversion routine, 
which converts constants to binary representation; 
and the name table routine, which tabulates informa- 
tion about all names used in the program. 
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Figure 33. FORTRAN IV Compiler Overall Flow of Processing 



Phase A 

Figure 34 shows the flow of phase A processing. The 
phase A source statement scanners perform complete 
processing of all program statements except the data 
and format statements. For nonexecutable statements, 
processing results in the tabulation of information con- 
tained therein. For executable statements, processing 
consists of both tabulation and compilation. Compila- 
tion is the process whose final result is the transforma- 
tion of a source statement into a sequence of machine 
instructions. Phase A compilation generates sequences 
of one-word and sometimes two-word internal instruc- 
tion formats ( iif's ) . If a sequence of iif's is associated 
with the same internal formula number ( ifn ) , a word is 
added to the sequence to contain this number (see 
"Internal Formula Number Generation"). Internal in- 
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are called main file iif's. 

Main file iif's are subsequently transformed by the 
phase B assembly processor into machine instructions. 
Certain main file ht's ( such as those related to subscript 
variables) are not complete when produced by the 
statement processors. For these cases, supplementary 
processing, such as is described later in Relcon analysis 
and Nestag processing, provides the additional infor- 
mation in time for the assembly processing. 

Phase A processing proceeds in a statement-by-state- 
ment manner. However, when the end of a do nest is 
reached, that is, the final statement of an outermost do 
has been processed, control is passed to the Nestag 
processor. This routine performs an analysis of the 
entire nest, resulting in the generation of indexing in- 
structions associated with the nest. The do indexing 
iif's are called Dotag file iif's. They are inserted at 
various locations in the main file containing the do nest, 
though they usually are at the beginnings and ends 
of the separate dos of the nest. The fact that they must 
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be inserted implies that a merge of the main file and 
Dotag file iifs must subsequently occur in phase B. 

The final output from phase A is the interphase 
tables file, which consists of tables required for phase 
B processing. 

The main file, the Dotag file, and the interphase 
tables file are placed on the system utility tapes, sysuts, 
sysuti, and sysut4, respectively. The main file and the 
Dotag file are created and written through double 
buffering during the course of phase A processing. The 
interphase tables file is written directly from working 
storage at the end of phase A processing. If a compila- 
tion is not being phased, sysut4 is not used. 



Phase B 

Figure 35 shows the flow of phase B processing. Input 
to phase B is the main file, the Dotag file, and the inter- 
phase tables file. Relcon iif's ( indexing instructions re- 
ferring to statements that occur outside do nests ) are 
generated at the beginning of phase B. These instruc- 
tions apply to subscripted variables with subscripts of 
one or more integer variables. 

After Relcon iif's are generated, the data and for- 
mat statement processing is performed. Next, storage 
is allocated, and the storage map is generated and 
printed. Finally, iif's from the main file and the Dotag 
file, and Relcon iif's from storage tables, are merged 
during the main assembly pass, resulting in the gener- 
ation of Loader text. In addition, prologue (initializa- 
tion) instructions are created where applicable. 




Storage Allocation 
Routine. Output 
a Storage Map 



Main Assembly Pass 
Merging Main File, 
Dotag File, Relcon 
File IIFs 



Exit 



Assembly Processing 

In order that phase B of the compiler may perform the 
assembly, all symbols of the program must be assigned 
relative core storage locations prior to the start of the 
assembly. For Internal Formula Numbers (ifn's) this 
is accomplished by treating each ifn as the beginning 
of a specially tabulated block of coding. ( See the sec- 
tion "Internal Formula Number Generation.") For 
source program symbols, other than statement numbers 
(External Formula Numbers or efn's), this is accom- 
modated by the core storage layout of the program. 
( The treatment of efn's is explained in the section "In- 
ternal Formula Number Generation.") 

The core storage layout of the object program is such 
that program data, consisting of program variables and 
arrays, are assigned core storage locations ahead of the 
executable program instructions. Program constants, 
parameters, and intermediate storage are assigned 
locations immediately following the program data. 
Since information as to their total size is accessible 



Figure 35. Phase B Flow of Control 



before the start of the second pass, this leaves the in- 
determinately-sized part of the program for the last 
stages of assembly. This part of the program may be 
regarded as composed 0i proper instructions ^ consist- 
ing of instructions from the main file, the Dotag file, 
and Relcon processing) and prologue (initialization) 
instructions. Prologue instructions are the most in- 
determinate with respect to size since they are not 
known until after the proper instructions have been 
assembled. Therefore, the prologue instructions are 
assembled last. They are appended to the end of the 
assembled program, but are executed first. 

Internal Formula Number (IFN) Generation 

An ifn is created when it appears possible that the 
associated instruction may be referred to by another 
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instruction in the program, or when it appears possible 
that, at a subsequent stage of processing, additional 
compiled instructions will be inserted at that point. 
More generally, an ifn is created when a reference 
may be made to the associated instruction either at 
object time or during process time. In the latter case, 
it is needed for the assembly merge. 

ifn's go into a sequentially increasing ordered table 
that contains a count of the total number of iif's gener- 
ated for each ifn of the table. More than one instruc- 
tion generator may contribute to the iif count for any 
one ifn. Each ifn table entry is created at the point 
in the compilation where the ifn is encountered. 

For ifn's associated with external formula numbers 
(efn's), a different technique is used since the efn is 
often encountered before its proper sequential location 
in a program. As an example, consider the statement 
GO TO 50 

where statement number (efn) 50 occurs at a later 
point in the program than the go to statement. In this 
case, the reference to the ifn that later will be associ- 
ated with the efn of 50 is made indirectly through the 
efn table entry created by "hashing" for value 50. 
("Hashing" is explained in the section "Table Con- 
struction." ) When statement 50 is actually reached dur- 
ing statement processing, the efn entry is given a 
pointer showing the true ifn table entry. 

The executable statement processors and the Nestag 
routine in phase A, and the Relcon routine in phase 
B, each contribute to the count recorded in the ifn table 
entries. Thus, when the phase B assembly routine as- 
sumes control, it can define the location of each ifn 
by using a simple cumulative totaling method. The 
relative location of each ifn is then defined as the total 
count appearing before the ifn in the ifn table. 

Internal Instruction Formats (IIF's) for Main File 

The primary contributors to main file instructions, 
quantitatively, are usually the arithmetic translator, 
which processes arithmetic and logical statements; the 
input/output list processor; and the if and the go to 
statement processors. Main file iif's may be incomplete 
with respect to address fields and index register (or 
tag) fields. The address field of an iif generated by 
either an if or a go to statement processor contains a 
pointer to an efn entry. This pointer is subsequently 
replaced by a pointer to an ifn table entry. The address 
fields of iif's generated by the arithmetic translator and 
the input/output list processor may be pointers to either 
the name or the subak table. 

If the field refers to a simple variable name, a pointer 
to a name table entry is used. If the reference is to a 
subscripted variable with constant subscripts, a pointer 
is provided to a subak table entry that consists of an 



array name plus a constant addend, iif's referring to 
other subscripted variables may require an address field 
that either refers to a subak table entry or must be 
initialized at object time. In addition, an index register 
may be required for the iif. 

The fortag table, which contains information con- 
cerning subscripted variables appearing in the source 
program, is used in supplementary processing (e.g., 
Nestag and Relcon routines ) to provide the assembler 
with this additional information. 

Internal Instruction Formats (IIF's) for Dotag File 

The Nestag routine produces Dotag instructions. These 
are indexing instructions that arise from the configura- 
tion of the following factors within a do nest: the do 
statements comprising the nest, parameters of the do 
statements, definition points for these do parameters, 
subscripted array variables, definition points for integer 
variables appearing in subscripts, and program trans- 
fers. The preceding elements generate sets of instruc- 
tions consisting mainly of the following major 
categories : 

1. Index register load value computation instructions 
— occur at do beginnings. 

2. Actual index register loading instructions — occur 
at do beginning. 

3. Index register increment value computation in- 
structions — occur at do beginning. 

4. Actual index register incrementing instructions — 
occur at do endings. 

5. End of do test value computation instructions — 
occur at do beginnings. 

6. Actual end of do testing instructions — occur at do 
endings. 

7. Computation instructions for iif address initializa- 
tion — usually occur at do beginnings but may also 
occur within the do. 

8. do transition instructions 

a. Bridge instructions for a normal exit from an 
inner do to an outer do — occur at both inner 
do beginning and ending. 

b. Trasto instructions for a transfer exit from an 
inner do to an outer do — occur completely out- 
side the nest. 

Internal Instruction Formats (IIF's) from Relcon 
Analysis Routine 

The Relcon instructions are indexing instructions that 
arise from the appearance of subscripted array vari- 
ables outside of a do nest. The sets of iif's generated 
from Relcon instructions fall into the following two 
categories: 

1. Index register load value computation instruc- 
tions. These may be compiled either in-line or as 
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closed subroutines (called releontines ) . In the latter 
case, a tsx instruction linking to the relcontine is also 
generated. 

2. Actual index register loading instructions. 

Both the Nestag routine and the Relcon routine per- 
form index register assignment by relating fortag 
table entries (corresponding to subscript combina- 
tions) to specific iifs which are otherwise complete. 
Absolute index register assignments are passed to the 
assembly routine by means of symab table entries. 
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Table Handling 

Table handling is accomplished by the Table Routine, 
which uses a pool of chained buffer areas. These areas 
are called tr ( table routine) buffers. 

Temporary areas for the various Compiler processors 
are included in these buffers. When a table or tem- 
norarv area is no longer needed the relevant buffer 
space is freed for subsequent use. 

Tables in which duplicate entries must be found are 
treated by a hashing technique to avoid sequential 
searches for duplicates. Hashing provides the location 
of a special, compact pointer table that, in turn, points 
to the location of the entry in the tr buffer area. The 
purpose of this indirect referencing technique is to 
avoid the scattering of table entries — with the con- 
sequent loss of core storage space — that occurs with 
most similar techniques. 

The layout of the tables in the tr buffer area shared 
by all processors is such that one set of tables ( the inter- 
phase tables) is allocated core storage moving from 
numericallv hi^h to numericallv lower locations while 
the remaining tables occupy storage moving in the 
opposite direction. See Figure 36. A table-overflow stop 
occurs during compilation only when these two areas 
overlap. A diagnostic message is generated if this 
happens. 

Within the lower set of tr tables, many of the tables 
go into subsets applicable only to a current do nest. This 
enables these particular tables to be erased when 
Nestag processing for the do nest is complete. The 
space can then be made available for further use. 

The Table Routine is common to both phases A and 
B. Processors in these phases accomplish their handling 
of (storing of, searching for, retrieving, etc.) table 
entries through the use of special macro-instructions, 
each designed to perform a special table-handling func- 
tion. The property of these macro-instructions that 
makes them especially valuable is that the calling proc- 
essor need not know the location of sequential table 
entries, which may be in separate buffers with widely 
differing core storage locations. 
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Figure 36. Core Storage Layout for FORTRAN IV Compiler 



Diagnostic Handling 

The error message processor is the last main component 
of the Fortran iv Compiler. Its function is to print 
diagnostic information about errors discovered by the 
various processors in phase A and phase B. 

Preliminary Error Handling 

The diag Routine is read into core storage along with 
Fortran Compiler control, and it remains in storage 
during compilation and assembly (phases A and B). 
The diag routine constructs the control and diagnostic 
( condig ) table, which contains the following informa- 
tion to be used by the error message processor: 

1. The sequential number of the error; i.e., first error, 
second, etc. 

2. The message number that identifies the message. 

3. The error level. 

4. The bcd message inserts. 
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Error Message Processor Action 

The error message processor is called at the end of 
phase B processing ( that is, at the end of an assembly 
or assemblies) if any error has been detected during 
phase A or B processing. This routine causes error 
output to be printed as follows: 

1. The error message processor places the following 
identification in the subheading of each page: 

COMPILATION yyyy 
where yyyy is the program name for which the related 
error messages are being printed. 

2. The error message processor begins the diagnostic 
messages from phase A with the message: 

DIAGNOSTIC MESSAGES 

3. The error message processor heads the diagnostic 
from phase B with the message: 

PHASE B DIAGNOSTIC MESSAGES 

4. For each error occurring during the operations of 

either phase A or phase B, the routine causes printing 

of one of the following lines as the first line of a 

message: 

i SOURCE ERROR j LEVEL k-xxxx 

or 
i LOGIC ERROR j LEVEL k-xxxx 

where i is a sequential number that the diag routine 
assigns to this message for this source program, j is the 



actual error message number, k is a number from one 
to five representing the severity level of the error and 
xxxx is the error level explanation. 

The significance of the value k and the explanation 



xxxx is : 

LEVEL (k) 
1 

2 
3 
4 
5 



EXPLANATION ( XXXX ) 

Warning Only 

Loading Suppressed 

Assembly Deleted 

Compilation terminated, error scan continues 

Compilation abandoned 



5. The error message processor then causes the 
second line of the message to be printed. Insert infor- 
mation comes from the control and diagnostic table. 
For example, the second line of the message may be: 
THE VARIABLE xx IS NOT DIMENSIONED 

where xx is the bcd message insert. 

The error message processor uses the control and 
diagnostic table to find the proper error message and 
its corresponding bcd message inserts, if any. This table 
is unique in three respects: 

1. It always begins in core storage location ocphaf. 

2. Its length for the diagnostic messages of each 
compilation is always less than or equal to the length 
s n ecified in storage location zcdin. 

3. It remains in core storage for the duration of the 
compilation of a program set. 
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COBOL Compiler Information 



The 7090/7094 cobol Compiler (ibcbc) is the com- 
ponent of the ibjob Processor that translates a cobol 
source program into the map language. The cobol 
language was developed for business applications by 
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Language (codasyl), as a cooperative effort of com- 
puter users in industry, the Department of Defense, 
and other Federal Government agencies and computer 
manufacturers. 

The 7090/7094 cobol Compiler (ibcbc) operates 
under the control of the Processor Monitor, which is 
under the control of the System Monitor ( ibsys ) . 

Input to the cobol Compiler is a cobol source pro- 
cram \X7nir>h noc r»p>or> mif nntn tVip ci7ctom -it-it->i-iJ- -i-it-h'J- 
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(sysini). Output from the cobol Compiler consists of 
the following: 

1. An augmented replica of the source program on 
the system output unit ( sysoui ) 

2. A list of messages describing errors detected dur- 
ing compilation (also on the system output unit) 

3. A tape of generated symbolic instructions 

At the conclusion of a compilation, control is re- 
turned to the Processor Monitor, which calls upon the 
Assembler to assemble the generated symbolic instruc- 
tions in a form acceptable to the Loader. 

The cobol Compiler consists of 11 program seg- 
ments, which are shown in Figure 37. The first of these 
remains in core storage throughout the compilation 
process. The other 10 segments are loaded into core 
storage successively, with each new segment replacing 
all or most of the preceding segment. Loading of the 11 
segments occurs once for each compilation of a source 
program. 

These 11 segments are discussed in the order in 
which they are brought into core storage. The dis- 
cussion is quite general, and highly important sub- 
routines are mentioned briefly. 



Segment I 

Segment i of the cobol Compiler is loaded first and 
remains in core storage throughout the compilation 
process. The program portions of this segment are 
described in the following text. 

COBOL Supervisor 

This portion of the cobol Compiler has three primary 
functions : 
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Nucleus (IBNUC) 



Input/Output Executor (1QEX) 



IBSYS 



Input/Output Buffer System (IOBS) 



Monitor (IBJOB) 



COBOL Compiler (IBCBC) 

Permanent Segment (Segment I) 



Compiler Infernal Dictionary (TBIDIC) 
Compiler General Table Area 



Compiler, Current Phase (Note 2) 
(Segment II, Environment I, Data I, 
Data II, Procedure I, Procedure II, 
Data III, Environment II, Procedure 



Compiler Input/Output Buffers 



Customer Accounting Subroutines 



D 



Note 1 



Notes: 



1 . Boundaries indicated by arrows fluctuate dynamically 
during compilation, according to need. 

2. The various segments listed are placed in this portion 
of core storage consecutively, no segment being re- 
placed until it has completely finished its assignment. 



Figure 37, Core Storage Map for the 7090/7094 cobol Com- 
piler 



1. It prepares all lines of communication with the 
ibjob Processor and initializes all cobol Compiler in- 
put/output operations. 

2. It controls the processing flow for all major phases 
of the cobol Compiler. 

3. It returns program control to the ibjob Processor 
and indicates whether or not a call is to be made to the 
Assembler. 



General Purpose Subroutines 

COLAG (Collection Agency): This subroutine re- 
ceives generated coding from various portions of the 
cobol Compiler and converts it to symbolic form for 
the Assembler. 

CITRUS (Coalesced Indirect Table Reference Un- 
ification Scheme): Most of the tables used within the 
cobol Compiler are under control of the general table- 
handling citrus subroutine. 

ERPR (Error Print): As source program errors are 
detected by various portions of the cobol Compiler, 
requests for generation of the related error messages 
are directed to this subroutine. 
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GETBUF and PUTBUF (Internal File Handler): 
Certain files, notably those for intermediate forms of 
error messages and of procedure text, are handled so 
that automatic overflow onto tape occurs when the 
capacity of an assigned core storage area is exceeded. 

DICT1 (Dictionary Lookup Subroutine 1): This sub- 
routine is used during the first scan pass (for each 
source program division ) to determine whether a name 
has occurred before. It is also used to enter newly de- 
fined names in the External Dictionary. (Correspond- 
ing to each External Dictionary entry there is an 
Internal Dictionary entry containing information about 
the item. ) 

DICT2 (Dictionary Lookup Subroutine 2): This sub- 
routine is used during the second scan pass (for each 
source program division) to determine whether a 
previously undefined name can now be defined. The 
dict2 subroutine is closely related to the dicti subrou- 
tine, and the two share many instructions. 

ULSC (Unit Level Scan): This subroutine is used 
extensively during the first scan pass ( for each source 
program division ) to isolate and classify the word units 
of the source program text. 

GLSC (Group Level Scan): This subroutine calls 
upon the ulsc subroutine and classifies groups of units. 

GRIN (Group Interpreter): This interpretive sub- 
routine compares encoded main program questions 
against classified answers from the glsc subroutine and 
chooses main program instructions to be executed 
based on the test results. The ulsc, glsc, and grin 
subroutines are used only for first pass scanning. 

PUTCP and PUTCPM (Constant Pool Handler): 
This subroutine saves generated numeric constants 
(avoiding redundant generation) for actual generation 
by the Cleanup segment of the cobol Compiler. 

PUTSPM (Symbolic Constant Pool Handler): This 
subroutine performs the same kind of function as 
the putcpm subroutine, except that the constants are 
symbolic (represented by an encoded word-logic form 
called T2 text). 

GETBL (Get a Base Locator), GETGN (Get a Gen- 
erated Name), and GETTS (Get a Temporary Storage 
Word): These three subroutines perform the function 
of assisting the various portions of the cobol Compiler 
in the generation of instructions by supplying unique 
words of the desired type and by keeping count of the 
total number supplied. 

File and Table Control Blocks 

Each file using iocs and each table using the citrus 
subroutine require a control block. The control blocks 
for all of the files and the citrus tables used by the 
cobol Compiler are defined in Segment i. 



Transfer Table 

A table of simple transfers to the various general pur- 
pose subroutines appears in Segment i. Its purpose is 
to permit rearrangement of the subroutines without 
having to reassemble each segment of the cobol Com- 
piler to correct the subroutine references. 

Communication Words 

A region of communication words is maintained in Seg- 
ment i to maintain communication between two seg- 
ments of the cobol Compiler not simultaneously in 
core storage. 



Segment II 

The second segment of the cobol Compiler generates 
initialization instructions on the Assembler tape. It 
then proceeds through the Identification Division of 
the source program, recognizing the various entries of 
this division. The contents of each entry are moved 
unaltered to the output area. During a scan of the Iden- 
tification Division, Segment n looks for the A-margin 
appearance of any other division header. When a valid 
uivision nearer is uctecicci, or Wucn a scbend car^i or 
an end-of-file is found, Segment n returns control to the 
cobol Supervisor. If the source program has no Iden- 
tification Division, control passes immediately from 
Segment n to the cobol Supervisor. 



Environment I 

The Environment i segment is called by the cobol 
Supervisor to perform the scan of the source program's 
Environment Division. 
The primary functions of the Environment i scan are: 

1. During the scan of the special-names paragraph, 
dictionary entries are made to relate the cobol hard- 
ware names to the mnemonic-names and switch-status- 
names in the source program. 

2. During the scan of the file-control paragraph, 
a four-word entry is made into the dictionary for each 
file named in a select clause. The type of equipment 
( card or tape ) to which the file is assigned is noted by 
setting particular bits in the dictionary entry. Other 
information concerning each file is obtained during the 
scan of the Data Division File Description paragraph. 

3. For each file named in a select clause text is 
created. This text is used by Environment n to create 
file and label cards which are sent to the Assembler. 
The information pertaining to file-names, the unit or 
units to which the files are assigned, and the rerun 
and apply options specified are considered to be text 
and are placed into an internal file for subsequent 
processing by Environment n. 
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4. Upon encountering the source program data put logical records, the displacement of the item is 
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Data I 

The Data i segment of the cobol Compiler is loaded 
as soon as the key words data division are encountered 
in the source program. The principal functions of Data 
i are: 

1. To scan the Data Division of the source program. 

2. To build the Data Dictionary. 

3. To prepare text ( in core storage) for Data n that 
reflects the postponed problems of occurs, redefines, 
and value. The constants associated with value are 
also preserved in text. 

4. To prepare text for Environment n. This text con- 
sists of the File Description information concerning 

RECORDING MODE, BLOCK CONTAINS, RECORD CONTAINS, 

label record clauses, and the list of all data record 
names in each file. 

Upon encountering the Procedure Division, Data i 
returns control to the cobol Supervisor. 



Data II 

Using text from Data i and the partially formed internal 
Dictionary as core-located input, the Data n segment 
does the following: 

1. Assigns object-time base locaters and builds a 
table to record the assignment. A base locator is a 
location which normally points to the beginning of a 
logical record within an input or output buffer. A base 
locator is also a location assigned to serve as a pointer 
to the beginning of data after a variable length array. 

2. Generates an out-of-line subroutine which calcu- 
lates the length and byte of each data item. If the length 
of a data item is not known at compile time, because 
a suborganization contains an occurs . . . depending on 
. . . , clause Data n generates a length calculation sub- 
routine which also performs the function of updating 
the dependent base locator. Data n builds tables to re- 
cord which of the subroutines needs to be executed 
when the value of a given quantity is altered. A quan- 
tity item is a data item whose name appears after 
depending on in an occurs clause. 

3. Generates the core storage reservation for all 
fixed-location data items. This task is complex in that 
allowance is made for loading of the proper initial 
values of data items. 

4. Builds a table giving the object-time displace- 
ment of each data item. 

If a data item's location is dependent upon the con- 
tents of a base locator, as is the case with input or out- 
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word whose location is determined by the same base 
locator. For other data items, displacement is the dis- 
tance from the first data word in the area for working 
Storage items. 

When there are no more dictionary entries to be 
processed, the Data n segment returns control to the 
cobol Supervisor. 



Procedure I 

Procedure i is called upon by the cobol Supervisor to 

perform the first scan of the Procedure Division text. 

The major functions of the Procedure i segment are: 

1. Each procedure-name at point of definition in the 
Procedure Division is entered into the dictionary, and 
a text word is created which refers to that dictionary 
entry. 

2. Text words are created in an encoded form for 
each of the cobol words found in the source program. 

3. All references to source language names are 
looked up in the dictionary. If the name being proc- 
essed is a data-name, a text word is created which re- 
fers to the dictionary entry of that data-name. If the 
reference cannot be found, an error message is given. 
This case arises when the data-name is insufficiently 
or incorrectly qualified, or cannot be found. If the 
name being processed is a procedure-name, the text 
created for the procedure-name is in bcd form. Before 
this phase is completed, all source-language proce- 
dure-names are defined and entered into the diction- 
ary. During the Procedure n phase, bcd procedure- 
name references are looked up and encoded text is 
generated for them. 

4. Structural analyses are made of all source lan- 
guage statements to ensure that all source language 
verb structures conform to the prescribed cobol rules 
of composition. 

5. When the $cbend card is encountered, Procedure 
i returns control to the cobol Supervisor. 

The output of the Procedure i phase is a prelimi- 
nary form of word-logic text called Tl text. 



Procedure II 

Procedure n is called upon by the cobol Supervisor to 
perform the second pass evaluation of the Procedure 
Division text. The input to Procedure n is the partially 
developed Tl text generated by Procedure i. The ma- 
jor functions of Procedure n are: 

1. To supply final dictionary references for the 
name definitions deferred by Procedure i. If the ref- 
erence cannot be made, an appropriate error message 
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is printed. This happens when a name is either insuffi- 
ciently or incorrectly qualified, or is not defined at all. 

2. To arrange, augment, or convert certain verb 
structures, move corresponding is converted to sev- 
eral individual move sentences. The perform structure 
is converted to move and compute statements having 
embedded instructions which are to be sent to the 
colag subroutine during Procedure in. The at end 
clause of the read verb is changed to an if structure. 
stop verbs are changed to display verbs, followed by 
instructions which perform the object-time stop. 

3. To convert arithmetic and logical phrases to a 
form of Polish notation which is easily processed by 
the Procedure m code generators. 

The output of Procedure n is the completed form of 
Tl text with all dictionary references in the correct 
form. The text string is a series of Tl text words rep- 
resenting procedure-names at point of definition and 
verb clauses. 

Environment II 

The Environment n segment is called by the cobol 
Supervisor to perform the following functions: 

1. For each file named in a select entry, the file 
characteristics are summarized. This summation con- 
sists of the following: 

a. A comparison of each block size specification 
to the calculated lengths of the records in the 
associated file. 

b. A determination of whether or not all records 
in the file are the same fixed length. The in- 
formation is used by the read and write in- 
struction generators in Procedure in. 

c. A check to determine that at least one open and 
at least one close have been issued for each file. 

d. A check to determine that a file has not been 
specified as being both input and output. 

2. Certain initialization instructions are sent to the 
instruction collection agency (colag). These instruc- 
tions pertain to the opening of the checkpoint file and 
the determination at object-time of the type of unit 
( card or tape ) assigned to a particular file. 

3. An ibmap file card is generated onto the As- 
sembler tape for each file named in a select clause. 
For each labeled file, a label card, which contains 
the information from the value of clauses in the as- 
sociated File Dictionary description, is generated. 

Upon completion of the processing of all files in the 
source program, Environment n returns control to the 
cobol Supervisor. 

Data III 

The Data m segment is entered by the cobol Super- 
visor to perform the following functions: 



1. The Data in phase generates object-time subrou- 
tines which set pointer words, known as positional in- 
dicators, so that they address given array elements. 

Each subscripted data item in the source program 
is located at object time through a positional indicator 
(pi). A different position indicator is used for each 
unique subscripted reference in the Procedure Divi- 
sion of the source program. For example, the coding 

MOVE A(IJ,K) TOX. 

MOVE B(I, J, K) TOX. 

MOVE A (I, J, M) TOX. 

MOVE A ( I, J ) TO X. 

MOVE A(I,J,K) TOX. 

causes four position indicators to be generated. The 
last subscript reference does not create a new position 
indicator because it is identical to the first reference. 

For each position indicator generated in the object 
program, there is also a subroutine generated to set the 
contents of that position indicator. It is the function of 
Data in to extract from the Internal Dictionary the in- 
formation concerning the base of the array and the dis- 
tance between the elements within the array. Data in 
also generates the object-time subroutines that set the 
position indicators. Calls upon these subroutines are 
generated by the Procedure in Supervisor when they 
are needed. 

2. The Data in phase forms a table of all data items 
that contain a quantity item (including with each of 
the data items the subroutines called upon when the 
quantity changes). This table is used by the quantity 
item analyzer in Procedure in. 

3. The Data m phase places the base locator num- 
ber in the Internal Dictionary in the place of the level- 
number for those data items which are located by a 
base locator. 

4. A list is compiled of all variable-length records 
and also of all fixed-length records that contain a data- 
item described by an occurs . . . depending on clause. 
This list is used by the read instruction generator in 
Procedure in to call upon the appropriate length cal- 
culation subroutines to adjust the lengths and base 
locations of data items affected by a read statement. 

Upon completion of these functions, Data m returns 
control to the cobol Supervisor. 



Procedure /// 

At the time the procedure text becomes input to Pro- 
cedure in, sentences have been reduced to statement 
segments. Each such statement consists of a verb, or 
its equivalent, and its related operands. The supervi- 
sory program for Procedure in gives these statements, 
one at a time, to specific instruction generator pro- 
grams, the program chosen depending upon the verb 
under consideration. These instruction-generating pro- 
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grams produce the appropriate object-time instructions 
in an encoded form called T2 Text. 

Subscript Calculations 

Prior to routing each statement, the supervisory pro- 
gram examines the statement operands to find all oc- 
currences of Tl Text words that indicate subscripted 
data operands. For the first occurrence of each word 
within a statement, the supervisory program generates 
a call to the appropriate position indicator (array 
«^intQi.\ noinniotinTi eiiKrrmHriQ i These subroutines 
were generated during Data in, and the supervisory 
program is able to determine which one to use by con- 
sulting the Position Indicator Table. 

Treatment of Incoming Procedure-Names 
at Point of Definition 

The supervisory program gives incoming procedure- 
names directly to the instruction collection agency 



to the quantity item analyzer. This, in turn, issues the 
proper calls to the base locator and length calculation 
subroutines generated in Data n. 

Instruction Generators 

The source language statements open, close, read, 

WRITE, MOVE, DISPLAY, ALTER, GO TO . . . DEPENDING ON 

and if and if not are converted to machine language 
by means of a set of subroutines known as instruction 
generators. Certain other verbs are also handled by the 
same generators, having been changed to one of the 
above verbs before Procedure m is entered. 

After the procedure text has been completely proc- 
essed, program control is returned to the cobol Su- 
pervisor. 



Cleanup 

The Cleanup phase is called by the cobol Supervisor 
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struction generators. 

If the procedure-name is a paragraph name or a sec- 
tion name, i.e., not a generated name, and if the scope 
of a perform verb terminates with the preceding 
paragraph, the supervisory program generates an in- 
struction immediately preceding the procedure-name. 
This generated instruction has the following form: 

TRA* + 1 
It is modified to provide the perform return linkage. 

Computation of Variable Lengths 

A data item that appears as a data-name after the 
depending on portion of an occurs clause is known as a 
quantity item. If any of the instructions generated for 
a statement alter the object-time contents of any quan- 
tity item, each generator potentially involved (move 
and read, at present) adds these data items to a list 
which it builds throughout its functioning. When such 
a generator's functions are concluded, but before it re- 
turns control to the cobol Supervisor, it gives its list 



The primary functions of the Cleanup phase are: 

1. The symbolic constants that were placed into the 
Symbolic Constant Pool are sent to the instruction col- 
lection agency ( colag ) in regular instruction format. 

2. All error message references that were sent to the 
erpr subroutine are arranged in ascending order, ac- 
cording to the associated source language card num- 
bers. Each error message reference is expanded to a 
full error message form that is sent to the Input/Out- 
put Editor to be placed on the system output unit 

( SYSOUl ) . 

3. bss instructions are sent to the instruction collec- 
tion agency (colag) to reserve storage for base lo- 
cators, position indicators, and temporary storage and 
result storage locations. 

4. The constants placed into the Numeric Constant 
Pool are sent to the instruction collection agency 
( colag ) and placed on the Assembler tape in the form 
of octal constants. 

Upon completion of these cleanup functions, control 
returns to the cobol Supervisor. 
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Assembler Information 



The 7090/7094 Macro Assembly Program, ibmap, op- 
erates under the 7090/7094 ibjob Processor Monitor. 
Input for the Assembler comes either from the cobol 
Compiler or from programmer-coded map language 
instructions, ibmap provides loader input that is indis- 
tinguishable from that supplied by the Fortran iv 
Compiler. Thus, to the Loader, a source language pro- 
gram written in the cobol, Fortran iv, or map lan- 
guage appears in the same format. As shown in Figure 
38, assembler output is in the form of relocatable 
binary text. 



Assembler Design 

Assembler activity is divided between two main phases. 
Phase 1 consists of initialization and a pass (pass 1) 
over the source program to form program dictionaries. 
Phase 2 consists of interlude procedures and the second 
pass ( pass 2 ) by the assembly program. 



The interlude, which is the time between pass 1 and 
pass 2, is used to determine the values assigned to the 
various symbols. Pass 2 is made over an internal form of 
binary information, rather than over the bcd informa- 
tion of the original source program. 

The core storage layout diagram in Figure 39 shows 
the relative locations of routines, tables, and diction- 
aries as they occur during phases 1 and 2. 

Phase 1 

The main functions of phase 1 are to initialize the 
Macro Assembly Program and to create tables neces- 
sary for definition by interlude procedures. A general 
flow chart for phase 1 is given in Figure 40. 

Initialization 

The initialization routine, which receives control di- 
rectly from the ibjob Processor Monitor, performs the 
following four functions: 



MAP 
Language 
Program 



COBOL 
Program 



COBOL 
Compiler 
(IBCBC) 



IBMAP 
Assembler 



Loader 
(IBLDR) 



Figure 38. Assembler Input and Output 
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IBSYS System Monitor 
IBJOB Processor Monitor 
Input/Output Control System 
Input/Output Executor 


Primary Supervisor Communication Words 
File Blocks Constants 


Input/Output Buffers 


Common Subroutines 


Phase 1 Supervisor 


Phase 2 Supervisor 


Pass 1 Processor 


Interlude Routine 


Debugging Dictionary Routines 
Error Message Routines 


Macro Processor 


Pass 2 Processor 
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Pseudo-Operation Dictionary 


Ini- 
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Hash Table 


Name Table 


Internal Dictionary 



Figure 39. Core Storage Layout 
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Obtain Source Deck 
Read Source Deck 

1 . Construct Main Dictionary 

2 . Construct Pseudo-Operation 

Dictionary 

3. Convert Literals 

4. Process Macro Definitions 
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8 . Process DUP Expansions 
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Figure 40. Phase 1 General Flow Chart 



1. Examines the system unit assignment table in the 
ibsys System Monitor to locate the physical units to 
be used by the ibjob Processor in performing input/ 
output functions for the Assembler. 

2. Scans the sibmap or sibcbc control card and sets 
program switches (governing conditions pertaining to 
the entire assembly) according to the information in 
the variable field of that card. 

3. Places the operation codes of the instructions into 
the main dictionary. 

4. Places the system symbols requested on the sibmap 
card into the main dictionary. 

Upon completion of these functions, control is passed 
to the primary supervisor, which, in turn, passes con- 
trol to the phase 1 supervisor. The initialization routine 
is loaded with the pass 1 processor but is subsequently 
overlaid by the main dictionary. 

Pass 1 

Input to the pass 1 processor consists of the source text 
card images. During this pass, the entire source pro- 



gram deck is read. As each card is read, the following 
processing occurs: 

1. The main dictionary is constructed. Items entered 
into this dictionary are: 

a. Symbols in the name field 

b. Qualified symbols 

c. Location-counter symbols 

d. New operations that may be defined by 
operation-defining pseudo-instructions. 

The main dictionary is the main information table 
of the assembler and consists of the following parts: 

a. The name table, containing the external bcd 
representation of each program symbol to 
which the internal text refers. There is one 
entry for each symbol, and the table is formed 
nonsequentially by a scattering principle. This 
procedure minimizes the time for pass 1 text 
production, which requires the immediate re- 
placement of each bcd symbol by an internal 
identifier. 

b. The internal dictionary, containing one entry 
in binary form for each program symbol. The 
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dictionary is formed linearly (that is, entries 
are in the same order as in the source program ) . 
c. The reference (or hash) table, providing the 
necessary relationship between the scattered 
information of the name table and the linear in- 
formation of the internal dictionary. This table 
is half the length of the name table. 
During pass 1, two types of entries are made into the 
main dictionary. The first is called a real entry. This is 
an entry for which information is placed in both the 
name table and the internal dictionary. Reference table 
correspondence is also generated at this time. 

The second entry type is called a nominal entry. This 
is one for which only the symbol is entered into the 
name table. There is no internal dictionary entry; thus 
there is no reference table entry. Nominal dictionary 
entries are made when encountering variable field sym- 
bols for which no entries have yet been made in the 
dictionary. A subsequent real entry for a given symbol 
replaces the nominal entry. 

2. The pseudo-operation dictionary is constructed 
but is not placed into its final location since that area is 
occupied during pass 1 by the macro-skeleton table, 
which is a table of macro-expansions expressed in a 
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sentially of information in the variable fields of any 
pseudo-operations that may affect a location counter. 

3. Literals are converted to binary form and stored 
in a literal pool, which is a table of all unique literals 
appearing in the source program. 

4. Macro-definitions are coded and placed in the 
macro-skeleton table. 

5. Card images required by the expansion of a 
macro-instruction are produced from the macro- 
skeleton table. 

6. Card images required by dup pseudo-instructions 
are produced. 

7. The truth value of iff or ift pseudo-instructions 
is evaluated to determine whether or not to scan the 
following card. 

8. Internal text corresponding to each source pro- 
gram card is produced. Original card images are 
retained only for listing purposes. If listing is not re- 
quired (by the sibmap card option, nolist), the card 
images are deleted. 

9. Immediate symbols are assigned S-values at the 
point at which they are used. An immediate symbol 
is a symbol used in a set, ift, iff, or dup pseudo- 
operation, each of which must be evaluated during 
phase 1. The S-value of an immediate symbol is deter- 
mined as follows: if the symbol is defined by one or 
more set pseudo-operations, its S-value is the value of 
the variable field of the last such set encountered. If the 
symbol is not defined by a set, its S-value is either 1 
(if it has previously appeared in any name field in the 



program) or (if it has not appeared in a name field). 
Output from pass 1 (and, therefore, phase 1) con- 
sists of the internal text file (which is on tape), the 
internal dictionary ( which is kept in core storage ) , and 
the following internal files: 

File dictionary and label information 
Pseudo-operation dictionary 
Control dictionary 
Error message 
Constant pool 

When phase 1 is completed, the interlude and pass 2 
routines of phase 2 are brought into core storage and 
assembler control passes to the phase 2 supervisor. 



Phase 2 

The major work of the assembler occurs during phase 2. 
The flow of processing for this phase is shown in 
Figure 41. 

Interlude 

Input to the interlude routine consists of the file dic- 
tionary and label information, the control dictionary, 
and the pseudo-operation dictionary. During the inter- 
lude, processing occurs in the following order: 

1. The file pseudo-instruction file is examined. From 
this, information is used in construction of the file dic- 
tionary. Any necessary sfile and slabel card images 
are written at this time, and the file dictionary is 
printed. 

2. The pseudo-operation dictionary is brought into 
core storage. It overlays the area that was occupied by 
the macro-skeleton table during phase 1. The defini- 
tions of all location symbols are then determined. This 
consists of assigning either absolute or relative locations 
to all pseudo-instructions. 

3. The control dictionary is examined and defined. 
This dictionary is complete except for the inclusion of 
virtual symbols. The control dictionary enables the 
Loader, ibldr, to make cross-references among pro- 
grams. Each control dictionary entry consists of a 
binary coded decimal name for external identification, 
the entry length (that is, the number of words), and 
its position in the source deck relative to the beginning 
of the program. 

There are four types of control dictionary entries. 
The first type of entry, called a control-section entry, 
is a reference to a combination of instructions or data 
that is to occupy a contiguous block of core storage. 
This type entry is produced by the contrl and 
common pseudo-operations. 

The second entry type is called an external reference 
entry. It is produced either by a call operation or from 
a virtual symbol. In the latter instance, the symbol is its 
own external name. 
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Figure 41. Phase 2 General Flow Chart 



Entry-point entries constitute the third type of con- 
trol dictionary entry. They are produced by entry 
pseudo-operations and permit a point within a program 
segment to be referred to from outside the segment. 

The fourth type of entry is the even entry. Its func- 
tion is to force the current location counter to an even 
value to ensure an even address for the next instruction. 
Even entries are produced by even pseudo-operations. 

If there is any output from the interlude routine, it 
is in the form of error messages, sfile cards, and slabel 
cards. 

Pass 2 

Pass 2 performs the final assembly pass over the internal 
text. Phase 2 actually begins at this point. 



Input to pass 2 consists of the internal text file and the 
error message file (if one exists). During pass 2, the 
following functions are performed: 

i. The machine instruction corresponding to each 
text item is assembled. 

2. The assembly listing is prepared for the input/ 
output editor. 

3. The binary deck image is prepared for the input/ 
output editor. 

4. A determination is made as to which symbols are 
virtual, and the control dictionary is completed (see 
"Interlude" ) . 

5. The cross-reference usage table is prepared for the 
input/output editor. 

Upon completion of this pass, the control dictionary 
is processed to produce binary cards and list informa- 
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tion, if required by the options in the sibmap control 
card. 

In pass 2, any debugging information encountered 
during processing the internal text file is modified 
slightly. After processing the control dictionary, the 
debugging dictionary is formed, if specified by an 
option on the sibmap or sibcbc card. 

Next, the error message file is examined. Outlines of 
any messages issued during assembly are interpreted, 



and the appropriate text is sent to the input/output 
editor for listing. Lastly, if requested by the ref option 
on the sibmap card, the cross-reference usage of sym- 
bols in the object program is prepared for listing. 

Phase 2 output consists of the assembly listing and 
the binary deck if specified on the sibmap card. 

Upon completion of phase 2, program control is 
returned to the ibjob Processor Monitor. 
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Load-Time Debugging Processor Information 



The Load-Time Debugging Processor consists of rou- 
tines to compile the debugging request package sub- 
mitted by the programmer, execution time routines to 
recognize and interpret debugging situations, and 
postprocessor editor and translator routines to list de- 
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these routines are supplemented by actions of the 
Assembler and the Fortran Compiler in providing in- 
formation from the source decks for the Loader, and by 
actions of the Loader in loading the debugging instruc- 
tions for execution with the program. 



Sample source 
program on J 

SYSIN "^ 



Debug request deck 



FORTRAN deck 



Load-Time Debugging Operations 

Figure 42 shows the flow of load-time debugging op- 
erations. The source program is read in — normally 
from the system input unit. It must contain a debug re- 
quest deck preceding the actual program instructions. 
Segments of the program may be in the Fortran or 
map language, in the form of relocatable binary text, 
or in any combination of these. The cobol programmer 
can use load-time debugging by specifying debugging 
locations from an Assembly listing of the cobol deck. 



Debug comments 




into debug File 1 




Debugging dictionaries 



into load file 
(SYSUT2) 



MAP deck 



Previously 
assembled 
deck 



Reference tables 
and dictionaries 
into load file 
(SYSUT2) 




Debugging dictionaries 



and control information 
into debug File 1 (SYSCK2) 



Interpreter Subroutines 
loaded with object program 



Debug dumps 




File 1 transformed 
into tables in 

core storage 




into debug File 2 (SYSCK2) 



Debug File 1 
from SYSCK2 



Debug File 2 



fromSYSCK2 



▼ Debug dumps and comments on SYSOU 



Figure 42. Load-Time Debugging Program Flow 
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This type of debugging should not be confused, how- 
ever, with compile-time debugging for cobol decks. 

Load-time debugging is accomplished in the follow- 
ing steps: 

1. The debugging compiler routines store the com- 
ments that are to be listed with the dumps and use the 
debugging request packet to prepare reference tables. 

2. The Assembler and Fortran iv Compiler prepare 
debugging dictionaries from the actual program. 

3. The Loader sets up the debugging mechanism for 
execution with the actual program. 

4. The execution time routines perform the re- 
quested debugging actions during execution of the 
object program. 

5. The debugging postprocessor editor and trans- 
lator routines translate the dumps, establish their for- 
mat, and list them. 

As shown in Figure 42, a deck assembled before this 
job already contains a debugging dictionary. For this 
reason, no work by the Assembler or by the Fortran 
iv Compiler is needed, and the deck passes imme- 
diately to the Loader. 

Debugging Compiler Routines 

The sibdbl card that immediately follows the sibjob 
card in any load-time debugging job causes the ibjob 
Monitor to call the debugging compiler into storage. 
The compiler reads in the entire debugging request 
deck and produces two different sets of data: 

1. A series of reference tables are written out as the 
first part of the load file. These tables are headed by a 
bcd card with the code srdict starting in column 1. The 
information in the tables provides the execution time 
routines with the points in the program where debug- 
ging has been requested, symbols used in debugging 
statements, and instructions for dumping that were 
coded from the debugging requests themselves. 

Since one of the execution time routines, the inter- 
preter, is constructed on a modular basis, only those 
segments needed by the debugging requests are called 
into storage. For this reason, the reference tables also 
include a dictionary of interpreter control sections. 

2. The comments that the programmer wants listed 
in connection with the debugging dumps are written 
into the first file on sysck2. 

Upon reading a *dend card, the debugging compiler 
returns control to the ibjob Monitor. 

The next step is to prepare a dictionary of the sym- 
bols defined in the source program that can be com- 
pared with the symbols that the debugging compiler 
has already written on the load file from the request 
deck. This dictionary is prepared by the Assembler or 
the Fortran iv Compiler, depending on the program 
deck involved. 



Debugging Actions by the Assembler 

Modal and dimensional information has been supplied 
by the map programmer in his source program. The 
Assembler sets aside this data until its normal opera- 
tions have been concluded. It then creates a debugging 
dictionary for each deck it has read. If a full debugging 
dictionary has been specified on the appropriate con- 
trol card, the dictionary refers to all symbols contained 
in the assembled program. If the short dictionary has 
been requested, only those symbols specified by the 
keep pseudo-operations in a map source deck are in- 
cluded. 

The debugging dictionaries are written out on the 
load file as the last part of the relocatable binary deck 
produced by the Assembler. They specify for future 
debugging action the name of each symbol, its mode 
and dimensions, and its relative or absolute location. 

Debugging Actions by the FORTRAN Compiler 

The Fortran iv Compiler performs the same debug- 
ging actions on a Fortran deck as the Assembler per- 
forms on a map deck. The input is a program in 
problem-oriented language, and the output, as far as 
debugging is concerned, is a debugging dictionary in 
binary form. 

Debugging Actions by the Loader 

The Loader receives the series of reference tables and 
dictionaries in the load file as its debugging input. It 
sets up the debugging mechanism as follows: 

1. It loads a debugging program block into core 
storage directly after the job program. This block con- 
sists of debugging reference tables and the necessary 
execution time routines. 

2. It enters the prefix of each program instruction, 
before which debugging action has been requested, 
into an str insertion table, referred to by location. The 
Loader replaces each such prefix in the program with 
the prefix for an str instruction. The execution time 
debugging routines include an str supervisor to moni- 
tor each occurrence of an str in the program, and rou- 
tines to interpret the debugging requests associated 
with the str. 

3. It writes the debugging dictionaries created by 
the Assembler and the Fortran iv Compiler onto the 
first file on sysck2, along with other reference material 
needed by the postprocessor routines. 

Execution Time Routines 

The str supervisor monitors the action of all str in- 
structions in the job program. Each debugging str 
transfers control to the interpreter routines, which in 
turn perform the debugging actions requested in the 
instructions coded by the debugging compiler. The in- 
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formation requested in each dump is written onto the 
second file on sysck2. The str supervisor then performs 
the instruction which was replaced by the str and re- 
turns control to the program for further execution. 

Postprocessing: The Editor and Translator Routines 

When the job program has been executed, the ibjob 
Monitor transfers control to the debugging postproc- 
essor editor. The editor reads the first file from sysck2 
into core storage. This file now contains the dump com- 
ments saved by the debugging compiler, and the refer- 
ence tables and dictionaries produced by the Loader. 



The editor rearranges this data into a form more readily 
usable by the postprocessor translator, reads in the 
translator (overlaying most of itself), and transfers 
control to it. 

The translator reads in the dumped information 
previously written into the second file on sysck2 by the 
interpreter routines. The format and limits of each 
dump are established according to the request for it, 
and any associated comments are added. Each listing 
is then written on sysou for printing. At the end of its 
work the translator returns control to the editor, which 
in turn relinquishes control to the ibjob Monitor. 
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Loader Information 



The Loader is a component program of the ibjob Proc- 
essor system. It accepts all the assembled decks for a 
job application produced by the Assembler and/or the 
Fortran iv Compiler, transforms them into one exe- 
cutable object program, and then transfers control to 
this program. Figure 43 shows the relationship of the 
Loader to adjoining components in the system. 

Input to the Loader consists of a load file and those 
subroutines that the Loader selects from the ibjob 
Library for inclusion in the object program. The load 
file is a repository of data for the Loader from the 
Assembler, the Fortran iv Compiler, or the debugging 
compiler. It is normally kept on symbolic input/output 
unit sysut2. But if the entire program consists of binary 
decks from previous assemblies or compilations, the 
Loader can be instructed to use input file sysini as the 
load file through the nosource option punched on the 
sibjob card. The load file contains program decks as- 
sembled by the Assembler and the Fortran iv Com- 



piler on the current machine run, or decks inserted by 
the programmer from previous assemblies. If the pro- 
grammer has made special requests in regard to files 
or control sections, the load file will also contain the 
appropriate control cards. And if he has requested 
load-time debugging, there will be a deck of reference 
tables from the compiler section of the Load-Time 
Debugging Processor. 

While creating a single executable program from its 
input, the Loader deals with several problems. 

Absolute Address Assignment 

The Loader determines the absolute address that each 
instruction or data word in a program must occupy at 
execution time. Where instructions refer to addresses, 
the Loader assigns an absolute value to each reference. 
First, the Loader solves another problem. When 
parts of the same program are coded separately and in 
different source languages, they are assembled as 
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separate decks. Even though each deck received by the 
Loader has been assembled into the same binary for- 
mat, the address locations are relative only to other 
locations in the same deck. Some address references 
may have no value at all, since they refer to symbols 
within another deck. The Loader precedes absolute 
address assignment by resolving the relationships 
among the decks themselves. 

Program Loading 

Even when all addresses and address references have 
been made absolute, the program must be loaded into 
its proper storage position for execution. At this stage 
in Loader operations, the parts of the program may be 
scattered over several areas of storage. The Loader uses 
a technique called "scatter-loading" to bring the object 
program into its proper position. 

Library Subroutines 

The Loader can add standard subroutines from the 
Processor Library (iblib) to the object program. Some 
of the subroutines, such as .lxcon, which controls post- 
execution operations, are added automatically to every 
program. The Loader selects others, such as the .lovry 
subroutine for loading overlay links, when the object 
program requires them. However, most Library sub- 
routines are loaded because the input decks or other 
Library subroutines require them. 

Input/Output Environment 

The Loader provides the input/output environment 
necessary for execution of a program. It assigns input/ 
output units to files, allocates buffer storage to files, 
chooses the appropriate input/output control routines 
for the program's needs, and generates the instructions 
necessary for initializing these routines. 

Overlay 

When the object program and its work area require- 
ments are too large for core storage, the programmer 
can request the Loader to set up an overlay pattern by 
using sorigin and sinclude control cards. Overlay mode 
alters Loader operations considerably. Absolute ad- 
dresses within different links, for example, may be the 
same, and a different series of debugging routines must 
be called in for load-time debugging. The Loader also 
performs an extensive checking operation to determine 
the validity of calls that would cause links to be loaded. 

Load-Time Debugging 

When the programmer has requested load-time de- 
bugging, the load file contains information from the 
debugging compiler based on his requests. The as- 



sembled decks generated by the Assembler and 
Fortran iv Compiler also contain dictionaries that will 
help the Loader define the symbols used in these re- 
quests. Using this material, the Loader constructs a 
mechanism that dumps the information during program 
execution, as requested by the programmer. 

Communications from the Loader 

The Loader reports program or machine malfunctions 
through error messages. (See part 3 of this manual 
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It reports input/output configurations with machine 
operator messages. On request it also lists a load map 
of core storage allocation at execution time, a cross- 
reference table of control sections and file names, and 
a buffer pool assignment list. 



Configuration of the Loader 

The Loader is divided into several parts. The first part 
is the load suprevisor, which is called into storage by 
the Processor Monitor (see Figure 44). It remains there 
throughout the Loader operations to call in the other 
parts of the Loader. These parts are an initialization 
section and the main program sections 1 through 5. 
( Another part, section 6, does not operate during load- 
time and is described in "The Librarian section.") 
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Utility Routines 
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Initialization Section 



Reserved for Section 5 



Installation Accounting Routine 



Location 00000 
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Figure 44. Storage Allocation for Load Supervisor and Initial- 
ization Section 
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Throughout its operations the Loader maintains two 
utility areas within the load supervisor section. The 
first is a communication area having the addresses of 
the tables, dictionaries, and lists with which the Loader 
works. The second area contains subroutines that are 
used in common by all Loader sections. 

Loader Operations 

Loader working storage requirements are such that 
part of a program having more than 6,000 instructions 
may have to be siphoned off into external input/output 
devices for temporary storage. The process may be 
called overflow or spill, depending on the conditions 
requiring it. The Loader performs this operation auto- 
matically by keeping a running estimate of its storage 
needs. A detailed description of overflow and spill, 
not essential to an overall understanding of Loader 
operations, is given later in this section. ( See "External 
Storage For Text." ) 

Since the Loader scans the program instructions part 
of the load file twice, it is called a two-pass loader. 
The first pass yields information used by the initializa- 
tion section and sections 1 through 3; second pass in- 
lOrrnation is useu uy sections i anu <_>. 

The following is a description of how these sections 
operate. 

Initialization 

The load supervisor is called into storage by the Proc- 
essor Monitor. It in turn calls the initialization section 
into upper core storage and part of section 1 into lower 
core storage. This part of section 1 consists of routines 
that are not used by section 2; it is to be overlaid when 
section 2 is brought into storage. The remaining section 
1 routines are used by both section 1 and section 2. 
They are read into upper core storage over the initiali- 
zation section after it has completed its work. 

The initialization section sets up an input/output 
environment for Loader use. It assigns input/output 
units, defines buffer pools, attaches files to the pools, 
and opens the files. One of the input files thus opened 
contains the input to the Loader. If no compilation or 
assembling of source language cards has been per- 
formed during this machine run, the input is read from 
sysin] . If there has been compilation or assembling, the 
input is normally in a load file on sysut2. If there has 
been compilation or assembling for only part of the 
program and the programmer has used a sibrel card, 
the Loader reads its input first from sysuts and then 
from systni , 

The first part of the load file is a deck of reference 
tables from the debugging compiler, if debugging has 
been requested. This deck is headed by a $edict control 
card. It provides information on the points in the pro- 



gram where debugging has been requested and on the 
symbols referred to in the debugging statements. It 
also contains instructions for dumping that were com- 
piled from the debugging statements themselves. 

The second part of the load file is a collection of 
program decks in binary format mixed with control 
cards generated by the Assembler, the Fortran iv 
Compiler, or both. These decks either have been as- 
sembled on the current machine run or added by the 
programmer from a previous run. Each deck contains 
a file dictionary (if input/output files have been re- 
quested ) , a set of relocatable binary instructions called 
"text," which are the binary translation of the source 
program instructions, a control dictionary section, a 
debugging dictionary (if debugging has been re- 
quested), and overlay control cards (if overlay has 
been requested). 

The load file also contains Loader control cards trans- 
mitted directly from the source deck by the Processor 
Monitor. These cards may appear in front of, between, 
or following the binary decks. 

In the section "Loader Input" there is a more detailed 
description of a load file. 

The initialization section now reads the first card 
image in the load file. If this card is not a sibjob card, 
loading terminates. 

The initialization section next transfers control to the 
installation accounting routine (if any) to record that 
the Loader is now in control. 

After receiving control again, the initialization sec- 
tion scans the sibjob card and encodes its parameters 
in the Loader communication area. 

If a srdict card appears directly after the sibjob card, 
the initialization section reads the debugging reference 
tables into core storage. The debugging tables are read 
in at this time, because section 1 uses them while read- 
ing the rest of the load file into storage. 

The initialization section then returns control to the 
load supervisor. If the next card on the load file is a 
sedit card, the load supervisor calls section 6 into core 
storage to edit the Subroutine Library (see "The Li- 
brarian" ) . Otherwise, the load supervisor calls in those 
parts of section 1 that are not already in core storage, 
overlaying the initialization section. 

Section 1 

Section 1 defines and attaches an iocs internal file buffer 
area for storing relocatable binary text. This file has 
all the properties of any other iocs file. All or part of its 
contents may also be transferred to any appropriate 
device, such as disk or tape. 

Section 1 now begins to read the rest of the data 
from the load or input files into four storage areas. 
Load-time debugging information is stored in a buffer 
attached to sysck2. The remaining areas are in core 
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storage and contain the internal text file for text, the 
control dictionaries, and the control information stor- 
age block, where additional control information is 
stored. 

This control information is stored in the form of 
chains of entries. In each entry is a word containing 
the addresses of the preceding and succeeding entries. 
Each chain is located by the Loader through a com- 
munications word that contains the addresses of the 
first and last entries. 

Chainin " sennits section 1 to store data in the con- 
trol information storage block without regard to the 
length of the chains and in such a way that the infor- 
mation can be found easily. 

Figure 45 shows section 1 and the working areas in 
storage. 

While transferring the load file into storage, section 
1 processes the data as follows: 

The options on the sibldr card, the first card in each 
binarv deck, are examined. Tf i/tbe annears the Heek 
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name punched in columns 8-13 is placed in a virtual 
section name list which is stored temporarily in the 
area reserved for section 5. This list is for section 2 
use in determining the subroutines to be included in 
the program from the Subroutine Library. Otherwise, 
the deck name is stored in the program name table 
chain in the control information storage block. This 
chain is to contain the name of every deck, including 
those in subroutines, that will appear in the program 
to be executed. If notext is punched, the Loader by- 
oasses all relocatable binarv text cards. 

If debugging has been requested, a search is made 
in the debugging reference tables for each deck name 
as it is encountered. If a match is found, corresponding 
chains within the debug tables are realigned accord- 
ingly. If there are no decks encountered for any names 
cited in the debugging reference tables, error messages 
are printed out. 

$fdict, $text, scDiCT, and sddict cards delimit sections 
of the binary deck. $dkend cards prepare the Loader 
for either a new deck or an end of file. 

Each file dictionary encountered generates an entry 
in the external file dictionary chain in the control in- 
formation storage block. This chain is used by section 2 
to generate file blocks. 

Each relocatable binary text card image is transferred 
directly into the internal file area in order of its oc- 
currence. 

Each two-word control dictionary entry is stored in 
the control dictionary area, and a third word is added 
for chaining control sections with the same name. 
These chains are called "like name" section chains. 
"Like name" section chains link together control sec- 
tions with the same name in all of the control diction- 
aries for a program. They facilitate absolute address 
assignment and the selection of subroutines to be in- 
cluded in the program. Control dictionary entries are 
ordered by their occurrence in the binary card input 
and are thus in ascending order within program decks. 
Control dictionaries from succeeding decks are stored 
in adjacent blocks. 

If the altio option has been specified on the sibjob 
card, the names of the normal Fortran input/output 
subroutines are changed to those of the alternate input/ 
output routines. 

The debugging dictionary in each deck is written 
out on the debug file. At the same time section 1 uses 
the entries to expand the debug reference tables. 

The first sorigin card sets the Loader to overlay 
mode. An entry is made for each card in the sorigin 
card chain in the control information storage block, 
and special entries are made in the program name table 
chain and appropriate control dictionaries. 

A sinclude card generates similar entries in the pro- 
gram name table chain and control dictionaries. 
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The contents of sname cards are stored in a jname 
card chain in the control information storage block, 
with added data from any $etc cards that follow. Each 
field on a card represents a separate entry in the chain, 
and entry lengths vary between three and eight words. 

The contents of the $use and somit cards are entered 
in a $use and $omit card chain in the control informa- 
tion storage block, with added data from related setc 
cards. The entries are similar in format to those of the 
sname card chain, but with a maximum length of three 
words. 

One entry for each spool or sgroup card and its as- 
sociated setc card is made in a spool and sgroup card 
chain in the control information storage block. The 
standard values for parameters that have been omitted 
on the card are also placed in the entry. The informa- 
tion stored in the spool and sgroup card chain is used 
by section 3 to allocate storage to buffer areas. 

One ten-word entry for each slabel card is made in a 
slabel card chain. Standard values for omitted options 
are entered automatically. 

One seven-word entry for each sfile card is made 
in a sfile card chain, with standard values for omitted 
options entered automatically. 

The size of Blank common is entered from a ssize 
card in the location ccsize. 

The standard entry point to the object program at 
execution time is entered from a sentry card into loca- 
tion ENTCC + l. 

Section 1 has now accepted all the data in the job 
application except subroutines from the Subroutine 
Library. It now uses the sname, suse, and somit card 
chains to modify information in the control dictionaries. 

The new control section names replace the old in the 
sname card chain. The same adjustments are made in 
any like name section chains associated with these 
names in the control dictionaries. All section entries 
are then removed from the sname card chain, leaving 
only file entries for section 2 use. 

A scan of the suse and somit card chain causes bits 
to be placed in the appropriate control dictionary 
entries. 

Section 1 now returns control to the load supervisor. 
The load supervisor calls section 2 into storage (see 
Figure 46 ) . 

Section 2 

Section 2 prepares the way for the Loader to assign 
input/output units and file buffers, generate iocs call- 
ing sequences, and give absolute locations to program 
parts. It determines the names of the subroutines that 
must be included as part of the program, and it builds 
up a body of cross-reference data for Loader sections 
that follow. 
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Figure 46. Storage Allocation During Section 2 Operations 

Section 2 first reads control information from the 
Subroutine Library into core storage. The Library is 
in three parts. The first part contains two lists of control 
sections: the subroutine name table and the subroutine 
dependence table. The second part contains the same 
control information as a load file: control dictionaries, 
file dictionaries, and Loader control cards referring to 
the subroutine text. The third part contains the re- 
locatable binary text of all the subroutines in the 
Subroutine Library. 

The subroutine name table contains the names of all 
real control sections appearing in the Library each with 
its file record or block number. The subroutine depend- 
ence table contains, for each entry in the name table, 
a table showing the other control sections that must be 
loaded with that control section. Section 2 reads these 
tables into core storage next to the control dictionaries. 
However, if the control information storage block and 
the control dictionaries section are so large that there 



is not enough space between them, the tables are read 
in over the section 1 routines in upper core storage. 

Section 2 now constructs a virtual section name list 
to tabulate all possible control section names that must 
be inserted in the program from the Library. First the 
names of the subroutines, such as .lxcon, that will be 
used automatically are added. Then the names of all 
control sections that are not defined in the program 
itself (i.e., virtual sections) are added. These virtual 
section names are added to the list through the 



1. Examines each control dictionary entry for its type 
and determines whether it has been marked for deletion. 

2. Deletes all entries for real control sections with 
the same name except either the first that occurs in the 
dictionaries or the one designated through suse and 
$omit cards. 

3. Examines all like name section chains for virtual 
control section names, i.e., names that have not been 
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These virtual control section names are added to the 
virtual section name list. 

The Loader next attempts to match up all names in 
the subroutine name table and the virtual section name 
table. When a match is found, the name of the sub- 
routine is entered into a required subroutine number 
list. This list is stored temporarily in the area that will 
be used later for section 5. If there are any names left 
in the virtual section name list after the comparison, a 
diagnostic is written on sysoui and a flag is set to sup- 
press execution. Otherwise, as soon as the list is com- 
pleted, it is sorted into numerical order based on the 
record or block numbers. 

The second part of the Library file is now processed 
to obtain the control information for routines entered 
in the required subroutine package number list. The 
routines used are the same section 1 routines in upper 
core storage used to process control information from 
the load file. If this part of section 1 has been overlaid 
by the subroutine name and dependence tables, it is 
now read in again over the subroutine name and de- 
pendence lauies i0r section ±. use, since me tauxes are 
no longer needed for processing. 

When all subroutine control information has been 
processed, section 2 uses the Equality Reduction rou- 
tine to chain subroutine and load file data in the control 
dictionaries. 

Where overlay is involved, the names on sinclude 
cards are now assigned to the proper links. In the 
program name table, the sinclude entries replace the 
other entries with the same name. In the control dic- 
tionaries, entries for control sections that are to appear 
in another link are flagged for section 4. 

call statements and references between links are 
analvzed for validitv. Downward call statements are 



marked in the control dictionaries as requiring transfer 
vectors. Unless noflow has been specified on the sibjob 
card, a call statement that would cause the calling link 
to be overlaid results in an error message. Virtual sec- 
tions that do not contain call statements and deleted 
real control sections are also checked for violation of 
overlay rules. Link numbers for subroutines that will 
be loaded into links on the overlay file are stored in the 
required subroutine package number list. 

The control dictionaries are now almost complete. 
All that remains is to account for Blank common, if re- 
quired. The Blank common name / / is entered in the 
program name table chain; a Blank common control 
dictionary is added to the control dictionaries area; and 
a like name section chain is set up within it. The length 
of Blank common is set to the largest storage area re- 
quested by any deck in the program, and the control 
sections for all other Blank common requests are de- 
leted. 

Section 2 next transforms those chains of information 
in the control information storage block that are needed 
by the remaining Loader sections into a more compact 
table form. These tables are stored in core storage di- 
rectly above the control dictionaries. 

The program name table chain becomes a separate 
table stored immediately after the required subroutine 
package number list. The original chain was composed 
of five-word entries. The first word is a chain to the 
other entries in the chain. The second contains the 
name of the Deck or subroutine. The third word is a 
chain to the appropriate external file dictionary chain 
entry. The fourth is a chain to the appropriate control 
dictionary entry. The fifth contains information for the 
overlay mechanism. In the process, the first word is 
dropped from each entry. 

File dictionary entries in the external file dictionary 
chain are renamed, using what remains of the sname 
card chain. 

A new table, called working file block 1, is made up 
from the sfile card chain entries. Each unique file 
name generates a 12-word file block within the new 
table. 

Working file block 1 is searched to find file names 
equivalent to the file name entries in the external file 
dictionary chain (i.e., comparing the sfile card entries 
with the references in the program file dictionaries ) . If 
a match cannot be made, an error message results, and 
the first word in each external file dictionary chain en- 
try is set to mze 0, signaling that references to the file 
are to be ignored. If a match is made, the file check 
portion of the external file dictionary chain entry being 
considered is transferred to a position in the appro- 
priate 12- word file block. The first word of the external 
file dictionary chain entry is changed to pze k, where k 
is the index position of the file block. 
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A file synonym list is made up from the external file 
dictionary chain and the file blocks for each deck that 
contains references to files. Each reference now has its 
corresponding entry in this list. The entry contains the 
constant to be added to the location of the first working 
file block to determine the location of the file block re- 
ferred to. 

The second word in each program name table entry 
is now changed to chain the entry to the appropriate 
file synonym list entry. Section 4 uses file synonym lists 
with the program name table to assign absolute loca- 
tions to file references in the program. 

A spool and sgroup list with buffer count specifica- 
tions is built up from a comparison of file names in the 
working file block to those in the spool and sgroup card 
chain. The spool and sgroup list entries are chained to 
the appropriate working file block entries. 

A working file block 2 is generated from each work- 
ing file block 1. This new block, which is later placed 
in the object program, is similar in format to working 
file block 1. 

Entries from the slabel card chain, if any, are 
stripped from the control information storage block 
and stored in the appropriate file blocks within working 
file block 2. 

Having created the cross-reference tables necessary 
to set up an input/output environment for the program, 
section 2 now completes its work by establishing the 
standard entry point to the program at execution time 
as follows: 

1. Location entcc is tested to determine whether an 
entry point has been named by a sentry card. 

2. If there is an entry point name, an equivalent 
name is sought in the control dictionaries. If none is 
found, execution is suppressed and an error message is 
written. If the name is found, its location in the pro- 
gram name table is put into location entcc and the 
name of the deck where the entry appears is put into 
location entcc + 1. 

3. If no entry point has been named, the Loader 
makes a search through the control dictionaries for the 

standard entry point name " ". If this is found, it 

is inserted in entcc, with its deck name in entcc + i. 

But if there is no entry point " ", the location of the 

first program name table entry is used, with its deck 
name. 

Having prepared the way for section 3, section 2 now 
returns control to the load supervisor. 

Section 3 

The Loader has the data it needs to create an input/ 
output environment for the program and to begin as- 
signing absolute address values to program sections. 
Section 3 is brought in to perform these tasks. Since 



all the essential data from the control information 
storage block has been stored in other reference tables, 
the load supervisor reads section 3 into this storage 
area. It also calls in section 4, since both sections use 
the same routine for storing the absolute binary text. 
Section 4 overlays the areas formerly occupied by sec- 
tion 2. (See Figure 47 for the storage configuration.) 
Since section 5 is included in the same system record 
with section 4, it is read into storage at the same time. 

Section 3 proceeds as follows: 

Using data from working file block 1, routine iouasg 
assigns input/output units to files and makes up a re- 
serve unit table listing its assignments. It then replaces 
the unit encodings in both working file blocks with the 
addresses of the appropriate unit control blocks in 

IBSYS. 

Unless nolist has been punched on the appropriate 
sfile card, routine oplist uses data from working file 
block 1 to print out file mounting messages to the ma- 
chine operator. 

At this point the Loader can start setting aside those 
parts of the program that are in their final form for 
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Figure 47. Storage Allocation During Section 3 Operations 



program execution. The Loader defines and attaches an 
internal file to contain these program parts until the 
entire program can be loaded. 

The most important parts of the program that will 
occupy this file are the program instructions when all 
absolute address values have been assigned. For this 
reason, the file is called the "absolute text" file. As 
indicated in Figure 47, section 3 uses the storage area 
formerly occupied by section 1 and the input buffer 
file for the new internal file. This file is a standard 
iocs buffer pool set up in scatter-load format for tem- 
porary storage of absolute text before the program 
is loaded into position for execution. As explained in 
the section "External Storage For Text," this file may 
at the same time exist as an external file attached to 

SYSUTl. 

Routine fpblk places working file block 2 and the 
reserve units table in the absolute text file. 

Routine rliob uses working file block number 1 and 
the spool and sgroup list to estimate the storage needed 
for program initialization. This area must include the 
following if required by the object program: routines 
to define buffer pools and to attach files to pools, in- 
structions to transfer control to an installation account- 
ing routine at the start of execution and to transfer 
control to the object program, a file list, and an inter- 
system reserve unit list, rliob uses this estimate to de- 
termine the origin of the program. 

Routine cdabs assigns an absolute address to each 
control dictionary entry. The preface entry of the block 
for each deck is marked to indicate the occurrence of 
deletions or insertions in that deck (i.e., whether there 
is a discontinuity in the location counter for that deck ) . 
The program name table is used to find the location of 
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is used in overlay job applications to assign the same 
absolute locations to links with the same logical origins. 

If the dlogic or logic option has been punched on 
the sibjob card, the cdlog routine prints out the logic 
cross-reference table from the control dictionaries. 

Since the amount of core storage that the object pro- 
gram and its subroutines will need at load time is now 
known, routine stass can assign the remaining storage 
as buffers for various files. Using the spool and sgroup 
list, working file block 1, and a series of its own tables, 
stass makes up the exact pool and group arrangement 
for each file, and the final input/output initialization 
block. This block includes the actual define and 
attach instructions for object program buffer pools and 
the final file list, stass also sets the absolute address of 
any nonstandard labeling routines and places them 
into the file list, stass checks the data in each file 
dictionary entry against actual file assignments. 

The Loader next generates iocs calling sequences 
and stores them in the absolute text file. It also gener- 



ates part of the call on the object program and all the 
linkage mechanisms between the ibjob Monitor job 
control section, the input/output instructions, and the 
object program. 

If the logic option has been selected, cdlog prints 
out the buffer pool assignment list. 

Communication words, defining the absolute location 
of object program file information that may be neces- 
sary for the object program or its postexecution control 
routine, are moved into the final absolute text file. 

If the map option has been punched on the sibjob 
card, routine maprog prints a load map of storage 
allocation and overlay link numbers for the object pro- 
gram. 

Section 4 

At this point in Loader operations the various source 
decks, subroutines, and control sections within the pro- 
gram that is to be loaded have absolute locations; the 
individual instructions do not have such locations. 
Tne Loauer must now maKe a seconu pass over the 
relocatable binary text file and control is passed to 
section 4 to perform this task. 

Section 4 completes all Loader functions except the 
actual loading of the program into position for execu- 
tion. It performs the following tasks: 

1. Assigns absolute addresses to all text words, in- 
cluding the text words of subroutines that will be used 
by the program. 

2. Sets up an overlay mechanism, if needed. 

3. Prints messages regarding text errors for each 
deck. 

4. Creates — and assigns absolute addresses to — the 
instructions that transfer control to the object program. 

Tf debnefffinff has been rennested. section 4 changes 
into absolute form the remaining relative addresses 
and address references in the debugging tables that 
will be used during program execution. These tables 
are now: 

1. A request dictionary containing the symbols used 
in the debugging request statements, with their abso- 
lute locations. 

2. An str insertion table for each deck in which de- 
bugging is to be performed, containing one entry for 
each point in the deck where dumps are to be made. 

3. A table of constants to be used by the debugging 
interpreter routines. 

4. The original debugging statements coded into a 
form more easily used by the interpreter routines. 

5. A control dictionary through which the Loader 
can load the proper debugging interpreter routines that 
are needed for this job application. 

Ordinarily, the combined subroutines and coded text 
is now stored in the absolute text file and builds 
downward toward the internal text file, as shown in 
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Figure 48. In the case of an overlay job application, 
however, only the main program ( link ) goes into the 
absolute text file. For this reason, the Loader must first 
set up the overlay pattern. Upon determining that an 
overlay job is involved, section 4 creates three reference 
tables to be used during execution of the object pro- 
gram. 

The link director table records the storage status of 
each link and points to the other reference tables. It 
consists of one-word entries, one entry for each overlay 
link. 

The link record chain lists the input/output units on 
which overlay links are written. It consists of two-word 
entries: one entry for each sorigin card and one entry 
for each control section containing text that was re- 
located in another link by means of a sinclude card. 

The transfer vector table consists of two-word en- 
tries, one entry for each call to a unique entry point 
that could cause the loading of overlay links. 
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Figure 48. Text Storage Allocation During Section 4 Operations 
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A fourth table, the link reference table, is retained 
by the Loader to control the writing of text into the 
link buffers. 

Section 4 next stores in the absolute text file the link 
director table, the link record chain, and the transfer 
vector table. These tables are all in an "overlay com- 
munication area" that is to be loaded with the main 
link. 

Section 4 now turns to the final assignment of abso- 
lute address values to the binary text of the program 
instructions. The Loader first creates control break 
tables, using the control dictionaries. There is one con- 
trol break table for each deck, reflecting all insertions 
and deletions that have occurred in previous process- 
ing. If the deck has no insertions or deletions, a control 
break table is not formed. 

The Loader next processes the text, word by word. 
When a dictionary reference is found, the control dic- 
tionary is used to assign it an absolute value. File 
references are evaluated in terms of the absolute ad- 
dresses of the file blocks, using the file synonym list. 
When subroutine text is to be inserted into the pro- 
gram, the Loader consults the required subroutine 
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processes the subroutine text in exactly the same man- 
ner. In overlay applications, the process is the same, 
except that special bits in the control dictionary entries 
cause the Loader to assign addresses in relation to link 
origin, and the text is transferred into the link file 
buffers, instead of into the internal text files. 

If overlay is involved, each word that is not in the 
main program is stored on the proper storage unit 
specified for its link. 

All Loader messages pertaining to text within a deck 
are printed as soon as the deck has been processed. 
The call to the object program is created and stored 
in the absolute text file. Next the Loader stores the de- 
bugging requests dictionary and str insertion table in 
the main link in absolute scatter-load form. The debug- 
ging control section dictionary and the str insertion 
table are coded to be written on the debug file. 

If debugging has been requested, the absolute loca- 
tion of each text word as it is processed is searched for 
in the str insertion table. If the location is found, the 
prefix of the text word following is placed in the ap- 
propriate entry in the str insertion table, and an str 
prefix replaces the prefix of the text word. 

Section 4 now saves certain words from the ibjob 
communication area that are needed by the executing 
program. One of these words, for example, is a transfer 
location for returning control to the ibsys Monitor. Sec- 
tion 4 stores the word in the postexecution routine 

.LXCON. 
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created. The Loader must still store them in the proper 
locations. Control is transferred to section 5 for this 
final task. 

As shown in Figure 49, section 5 works with two 
storage blocks: the absolute text file containing the 
scattered program parts, and an area between this file 
and ioex into which the program is to be loaded in the 
proper order for execution. This program loading area 
coniciiiis G8.I8. ins.! wim 3. rcw exceptions Brc or no use 
to the executing program: the ibjob Monitor, the load 
supervisor area, section 4, and the reference tables and 
control dictionaries used during section 3 and 4 opera- 
tions. 

Section 5 first determines whether loading should 
be performed. If nogo has been punched on the sibjob 
card or has been set due to a high level error during 
Loader operations, an error message is printed and 
control returns to the ibjob Monitor. 

If loading has not been suppressed, section 5 now 
prepares the program loading area to receive the pro- 
gram parts. It clears each storage location in the pro- 
gram loading area by setting it to: 
STR 0, ,0 
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Figure 49. Storage Allocation During Section 5 Operations 



The contents of the absolute text file are now scatter- 
loaded into the program loading area. Control words 
interspersed in the text direct segments of words into 
their proper program sequential positions. When the 
internal absolute text file has been read, it too is set to 
str's. 

The routine unisub removes the names of the input/ 
output units from the availability chains in the ibsys 
nucleus. 

If an operator stop for tape mounting is necessary at 
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The remainder of core storage up through the last 
few instructions of section 5 are now set to str's, and 
section 5 transfers control to the pre-execution package 
section of the object program. 

Control of Program Execution 

Among the program parts loaded by section 5 into 
position for execution, several work together as a pack- 
age to handle whatever may happen during execution. 
The package consists of: 

1. The object program file blocks 

2. The reserve units table 

3. The object program file list 

4. A group of pre-execution initialization instruc- 
tions 

5. The post-execution routine .lxcon 

The first three items in the package are omitted if 
there are no sfile cards in the object program or in any 
of the Subroutine Library subroutines being used in 
the program. 

Figure 50 shows how the package controls execution 
of the program. After Loader operations have been 
completed, section 5 transfers control to the pre- 
execution initialization instructions section. 

The pre-execution instructions transfer control to the 
installation accounting routine, if any, to record that 
program execution has begun. Buffer pools to be used 
by the program are defined, and files are attached to the 
pools. The last instruction is a call to the object pro- 
gram to begin execution. 

One of three events can occur as a result of program 
execution. (1) The program can execute successfully. 
(2) iocs may be unable to continue, resulting in a sys- 
tem stop. (3) The program can contain an str instruc- 
tion requesting a system dump. In all three cases, the 
program transfers control to .lxcon. After a successful 
execution the object program transfers control to 
.lxcon through the entry point .lxrtn. The entry point 
.lxstp is used for system stops; .lxstr is used for 
system dumps. 

.lxcon closes all open files used by the object pro- 
gram. If any one of the file blocks contains the options 
print, punch, or hold, the input/output unit involved 
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is rewound and unloaded, and a message for the opera- 
tor is printed on-line. Nonsystem units are returned to 
the unit availability chain, and the intersystem reserve 
characters, if any, are placed in the appropriate unit 
control block. 

If a system dump is requested by a transfer to .lxstr, 
.lxcon prints an on-line message indicating that a 
dump is being taken, closes all required files, and trans- 
fers to the system dump routine. If the transfer from 
the object program is through .lxstp, .lxcon prints an 
on-line system stop message and closes the files. In 
either case, program execution is terminated by a 
transfer to the installation accounting routine, if any, 
followed by a transfer to ibsys for the next processor 
application. 

Note: When load-time debugging has been re- 
quested, .lxstr is set to transfer to the debugging inter- 



preter routine. If the str was inserted in the program 
for debugging purposes, the interpreter performs the 
action requested for that program location and even- 
tually returns control to the object program. If the str 
has no connection with debugging and the routine for 
taking debug dumps is not in core storage, the inter- 
preter transfers to .lxcon for the normal action on an 
str. If, however, the coding for debug dumps is in core 
storage, the interpreter takes a full core storage dump 
and transfers to .lxcon through .lxrtn. .lxcon closes 
the required files, transfers to the installation account- 
ing routine, and then to ibsys. 

External Storage for Text 

External storage is used for two purposes during load- 
ing: to "overflow" and "spill" excess relocatable binary 
text during section 1 and 2 operations, and to "over- 
flow" absolute text during section 3, 4, and 5 opera- 
tions. Figure 51 shows how the external storage is used. 



IBJOB 
Monitor 



UT2 




UT4 



Section 1 
Input Reduction 





UT3 



Section 2 
Cross-Reference and 
Subroutine Analysis 




UT3 




Section 3 

Absolute Location 

Assignment 




Section 4 
Text Relocation 




Section 5 

Absolute 

Program Load 



IBJOB 
Monitor 



Figure 51. Overflow Pattern During Loader Operations 
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Overflow and Spill of Relocatable Text 

The relocatable text portion of each binary deck is read 
from the load file or input file and moved into an in- 
ternal file in core storage between the control diction- 
aries section and the control information storage block 
(see Figure 45). As the Loader continues to read in 
the binary decks, the control dictionaries section builds 
upward toward the internal text file and the control in- 
formation storage block builds downward toward it. 

Since neither section 1 nor section 2 process text in 
any way, the text can be transferred to any convenient 
place when it is in danger of being overlaid by data 
in the other two areas, or of exceeding its allotted in- 
ternal file space. 

This transfer can occur when the amount of text ex- 
ceeds the capacity of the internal file, in which case the 
excess thereafter overflows onto sysut4, or one or both 
of the other storage sections could threaten to overlay 
the internal file, in which case the entire internal file 
spills onto SYSUT3. 

Absolute Text Overflow 

External storage is also used during the absolute ad- 
dress assignment process. If the amount of absolute 
binary text produced by section 3 exceeds the absolute 
internal text file, the excess overflows onto sysuti. Dur- 
ing section 4 operations relocatable text is read back 
into storage from sysut3 and sysut4. If the absolute 
text produced by section 4 exceeds the absolute internal 
file, sysuti is used for the excess, sysuti is also used for 
words that, when scatter-loaded by section 5, would 
overlay a part of the internal file. Such words are held 
on sysuti along with the excess text produced by sec- 
tions 3 and 4 until section 5 time. When section 5 
scatter-loads the absolute text of the program into 
position for execution, it loads the text from the internal 
file first, and then the text in the external file on sysuti. 



Loader Input 

Input to the Loader consists of the load file and sub- 
routines taken from the ibjob Library. The "Subroutine 
Library Information" section describes the Subroutine 
Library format. 

The load file is made up of output from the Assem- 
bler, the Fortran iv Compiler, the load-time debugging 
compiler, or any combination of these three. It is writ- 
ten on symbolic input/output unit sysut2 for Loader 
use by the Processor Monitor. 

Figure 52 shows the possible contents of a load file 
and their sources. The elements in the figure from the 
sibldr card through the sdkend card make up a binary 
deck. There may be several such decks in the load file, 
depending on the number of source decks in the pro- 
gram. 



Element 


Card 
Format 




Load-time debugging 
reference tables 


BCD and 

Column 

Binary 


Debugging compiler 


SIBLDR card 


BCD 


Generated by Assembler or 
FORTRAN IV Compiler 


SFILE, SPOOL, SGROUP, 
SLABEL cards 


BCD 


Generated by Processor Monitor 
or transmitted directly from 
source deck 


$FD!CT card 


BCD 


Generated by Assembler or 
FORTRAN IV Compiler 


File dictionary text 


Column 
Binary 


STEXT card 


BCD 


Relocatable binary textof 
source program 
instructions 


Column 
Binary 


SCDICT card 


BCD 


Control dictionary text 


Column 
Binary 


SDDICT card 


BCD 


Debugging dictionary 
text 


Column 
Binary 


SDKEND 


BCD 


SENTRY, SSIZE, $USE, 
$OMIT,SNAME,$ORIGIN, 
SINCLUDE cards 


BCD 


Transmitted directly from 
source deck by Processor 
Monitor. May appear any- 
where between binary decks. 

~ . 



Figure 52. Elements of Loader Input 

In addition to the binary decks written on the load 
file during the current assembly process, the program- 
mer may also add decks punched from sysppi during 
previous assemblies. These previously assembled decks 
will be written on the load file in the same order as that 
in which the programmer has placed them in the orig- 
inal source program. If all the decks in the source 
program are previously assembled binary decks the pro- 
grammer may have the nosource option punched on 
the sibjob card for the job. The entire program in this 
case is read by the Loader directly from symbolic unit 
sysini. If the programmer adds a packet of load-time 
debugging requests to a program composed entirely 
of previously assembled decks, the nosource option 
is ignored, and the load file is built up on sysut2. 

Each section in a binary deck is prefaced by a bcd 
card. In each source card the code indicating the sec- 
tion of the deck that follows ( sfdict, stext, scdict, or 
sddict ) begins in column 1. The six-character name of 
the deck starts in column 8. The sibldr and sdkend 
cards that bound the deck as a whole are in the same 
format. 



Loader Information 93 



Each section in a binary deck is sequenced inde- 
pendently, starting with sequence number 0. The cards 
within any section must be in proper sequence and 
the sections themselves, if present, must be in the order 
shown in Figure 52. 

Load File Binary Cards 

The first two words on all load file binary cards are in 
the following form: 

WORDS BITS MEANING 

1 S, 1 If these bits are 11 and bit 3 is 0, this is a 

standard IB JOB Processor deck. 

2 If this bit is 0, the Loader must verify the check 
sum in word 2. If the bit is 1, no verification is 
required. 

3 This bit is usually a 0. If it is 1, an error mes- 
sage is printed indicating that the card is not 
part of an IBJOB deck. 

4 If this bit is 0, this is a load file deck. If it is 1, 
this deck is Prest or Cprest. 

5-7 These bits define the section of the deck as 

follows: 
001 means this card is in the file dictionary. 

010 means this card is in the relocatable text of 
the program instructions. 

011 means this card is in the control dictionary. 

100 means this card is in the debugging dic- 
tionary. 

101 means this card contains relocatable binary 
text produced by the Load-Time Debug- 
ging Compiler. 

8-12 01010. This is the standard 7-9 punch, signify- 
ing a column binary card. 

13-17 These bits contain the number of words in the 
card, starting with word 3. 

21-35 These bits contain the card sequence number. 
2 S, 1-35 This word contains the logical check sum of 
word 1 and all the data words on the card. 

The contents of words 3-24 vary according to 
whether the words are part of the file dictionary, re- 
locatable binary text, control dictionary, or debugging 
dictionary. 

File Dictionary Binary Text 

Words 3-22 of a binary text card in the file dictionary 
contain up to four 5- word entries, one entry for each 
file referred to in the deck. Words 23 and 24 are not 
used. 

The file dictionary, if present, is used to validate the 
contents of the Loader-generated file block and the 
assignment of each file to a buffer pool; to transmit the 
name of a nonstandard label section to iocs; and to 
pass the 18-character file name through to the Loader, 
so that correspondence can be determined between the 
file index numbers used in text and the file names used 
by the programmer. File type, mode, allowable input/ 
output units, and blocking requirements are normally 
unchanged by the generated object program; hence, 
they are recorded in the file dictionary as a check 
against modification by sfile cards. 



File Dictionary Card Format: The file check entries 
in each card are as follows: 



Words 3-7 
Words 8-12 
Words 13-17 
Words 18-22 
Words 23-24 



file check entry i 
file check entry i + 1 
file check entry i + 2 
file check entry i + 3 
not used 



The format of each five- word entry is: 

WORDS BITS MEANING 

1 S If = 1, mixed mode file 

1 If = 1, last fdict entry 

2 If = 1, file is nopool 
3-5 not used 

6 If=l, binary mode; if =0, bcd mode 

7-8 If =00, input 

If =01, output 

If = 10, input or output 

If =11, checkpoint 
9-14 not used 
15-17 If =001, card equipment only 

If =010, 729 Magnetic Tape, disk or Hypertape 

If =011, any input/output device 

If =100, Hypertape only 
18-20 If =000, n = block size ( see bits 21-35 ) 

If =001, n is the minimum allowable block size. 

If =010, block size is a multiple of n 
21-35 n 
2 If = 0, standard labels ( if any ) 

IMO, external reference name of nonstandard 
label routine 
3-5 18-character file name 

Relocatable Binary Text 

Relocatable binary text cards contain the binary trans- 
lation of the original source program instructions. 
Words 3, 4, and 5 are control words that describe the 
contents of words 6-24, which are the actual instruc- 
tions. 

The sign bit of each control word is ignored, and the 
remaining 35 bits are divided into seven 5-bit control 
groups. For example, in word 3: 

Bits 1-5 describe word 6 
6-10 word 7 



31-35 word 12 

In the same way, the control groups in word 4 de- 
scribe the contents of text words 13 through 19. The 
first five control groups in word 5 describe the remain- 
ing text words 20 through 24. 

The Loader uses the control groups when it assigns 
absolute values to addresses and address references. 
For this reason, the control groups are also called re- 
location bits. 

The first bit in each control group describes the type 
of text word. The number 1 means a standard data 
word; the number means a special entry word. 

Standard Data Word: The five-bit control group for 
a standard data word is of the form 1 ab cd. The 1 in- 
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dicates a standard data word. The letters ab and cd 
describe the contents of the decrement and address 
data fields, respectively, as follows: 

CODE MEANING 

00 This data field has a constant value. 

01 This data field has a simple relocatable value. 

10 This data field contains a file or control dictionary re- 
ference. The field itself describes which type. 

11 The Loader must evaluate a complex expression to de- 
termine the value of this data field. 

The prefix and tag of a standard data word are con- 

aiciiit.. 

For example, consider this instruction and its con- 
trol group: 

100 01 TIX NAME,1,4 

Reading the control group from left to right, this is a 
standard data word with a decrement of constant value 
and a relocatable address. 

Constant form — The relocation code 00 indicates to 
the Loader that the value expressed in the decrement 
or address referred to is constant and need not be 
altered. 

Simple relocatable form — The relocation code 01 
indicates to the Loader that the value expressed in the 
decrement or address referred to is a relocatable ad- 
dress, relative to the origin of the deck. As an example, 
consider the following instructions, where A has a 
relative address value of 100 and B of 163: 





CONTROL GROUP 




SYMBOLIC CODE 


IN BINARY 


BINARY TEXT IN OCTAL 


CLA A 


100 01 


0500 00 00100 


ADD A + l 


100 01 


0400 00 00101 


TXH B,4,A 


10101 


3 00100 4 00163 



Dictionary reference form — Dictionary references 
are denoted by a relocation code of 10. Eacn uata neiu 
referred to by bits in this form contains a 15-bit code 
identifying the dictionary reference. The four high- 
order bits in the field denote the type of dictionary, and 
the remaining bits give the reference number within 
the dictionary. The high-order bit codes are: 

000 Control dictionary reference, followed by eleven bits 
giving the relative location of an entry in the deck con- 
trol dictionary. 

000 1 File dictionary references followed by an eleven-bit file 
index number. 

As an example, consider the following instructions: 



SYMBOLIC CODE 
CLA A,4 
PZE AFILE 



CONTROL GROUP 

IN BINARY 

10010 

100 10 



BINARY TEXT IN OCTAL 

0500 00 4 00006 
000000 04013 



In both cases, the code 10 in the cd bits of the con- 
trol group indicates that the address portions of the 
words refer to dictionary entries. In the address portion 
of the first instruction the first two octal numbers, 00, 
appear in binary form as 000 000. The four high-order 



bits of these numbers, 000 0, indicate that A is a sym- 
bol in the control dictionary for this deck, and the low- 
order bits indicate that it is the sixth entry. In the ad- 
dress portion of the second instruction the first two 
octal numbers, 04, appear in binary form as 000 100. 
The four high-order bits 000 1 refer the Loader to the 
file dictionary for this deck. The low-order bits specify 
that afile is the eleventh ( 13 8 ) file referred to in the 
deck. 

Complex expression form — The relocation code 11 
indicates to the Loader that it must evaluate a com- 

.i i r .t 1 
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ment or address referred to. For example, the Loader 
would have to evaluate the address portion of this 
word as a complex expression: 

CLA 6*TABLE+2*TABLE + 3 

The steps in the evaluation are expressed in a series 
of words directly following the data word that contains 
the complex data field. The string of words can be in 
one of two forms — long-form complex or short-form 
complex — depending on what the data field itself con- 
tains. 

If the decrement or address field contains zero, the 
expression is long-form complex. A string of one or 
more words, each with its own control group, follows 
the data word. Each word represents a simple arith- 
metic step in the computation. If both the decrement 
and the address of the data word are complex, the 
string of words referring to the decrement occurs first. 

Each word in a complex expression string has the 

following form: 

pfx a,b,c 

Pfx defines the type of simple arithmetic operation to be 
performed, as follows: 



PFX 

PZE 
PON 
PTW 
PTH 



ARITHMETIC OPERATION 

addition 
subtraction 
multiplication 
division 



The address portion a and the decrement c are the 
first and second quantities, respectively, upon which 
the arithmetic operation is to be performed. 

The tag portion b refers to the location where the 
result of the arithmetic operation can be stored tem- 
porarily until needed later on in the computation. There 
are seven such locations, called result words. The 
Loader recognizes them by number, through 6. A 
tag of 7 indicates to the Loader that the current data 
word completes the computation, and the result should 
be stored in the data field being evaluated. 

For example, an evaluation word in this form: 
PTH a,l,c 

means to the Loader that the result of a -r c is stored 
temporarily in storage word number 1. 
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When the a or c portion of a word represents the 
result from previous arithmetic operations, the Loader 
finds the word where that result is stored as follows: 

1. In the control group for the word, relocation 
bits 11 indicate that the corresponding decrement or 
address in the word represents a result. 

2. The decrement or address itself contains the num- 
ber of the word in which the result has been stored. 

For example: 



RELOCATION BITS 
1 1111 



DATA WORD 

00001 1 00002 



indicates that both the c and a portions of this arith- 
metic operation are results of previous arithmetic op- 
erations in the string. The result in the c portion can be 
found in the first result word, and the result in the a 
portion is in the second result word. 

As an example of the words generated for a long- 
form complex expression, consider the instruction cited 
previously: 

CLA 6*TABLE+2*TABLE + 3 

where table is a control section whose location is to be 
assigned by the Loader. 

Assume that the control section named table is the 
fifth entry in the control dictionary. The data words 
instruction would appear as: 

RELOCATION BITS DATA WORD MEANING 

10011 050000000000 The address portion of 

this CLA instruction must 
be evaluated according to 
the following string of 
data words. 

1 00 10 2 00006 1 00005 The result of the opera- 

tion TABLE*6 is stored 
in result word 1. 

10010 2 00002 2 00005 The result of TABLE*2 

is stored in result word 2. 

1 11 11 00001 1 00002 The sum of the contents 

of result words 1 and 2 
is stored in result word 1. 

11100 000017 00003 The contents of result 

word 1 added to 3 are 
stored in the address por- 
tion of the first data word 
above. The computation 
is now complete, and the 
word is stored in the final 
text file, the remaining 
data words being disre- 
garded. 

If the decrement or address field in the data word 
does not contain zero, the expression is short-form com- 
plex. This form may be used to express complex fields 
of the following form: 

NAME+C 

where name is the external name of the control section 
and C is some constant. The 15-bit field is formed as: 



Bits 2 to n This is the entry number of NAME in the con- 
trol dictionary for this deck. As many bits are 
used as are required to express the total length 
of the control dictionary; e.g., if the dictionary 
contains 16 entries, 5 bits would be used— bits 2 
through 6. 

Bits n to 15 A constant of (15-n+l) bits to be added to, 
or subtracted from, the location assigned to the 
name referred to. Note that the long-form com- 
plex process may have to be used if the length 
of the control dictionary plus the length of the 
addend exceeds 14 bits. 

The minimum value of n is 6. 

As an example of evaluating a short-form complex 
expression, consider the instruction 

CLA BLOCK +50,1 

block is a control section 50 words long. Its control dic- 
tionary name, block, is the eighth entry in a 26-entry 
dictionary. The data word for the instruction is 
0500 00 1 10062, and the bits in the address field 10062 
are interpreted as: 

12 6 7 15 

01000 000110010 
+ 8 50 

Special Entry Word: Special entry data words refer 
to program origins, and to bss and vfd storage areas 

-n-^J ^+1,^- ,•„„*. ~*-;~~„ t-Ur.*- ~£C j. 1 j_: j. 

anu uuici niatxuwLiuiia mat ancvjt njtJctuuii cuumcis. 

Control groups for all special entry words are of the 

following form: 

SSSS 

The in the first bit denotes a special entry word 

The four bits SSSS that follow specify the type of special 

entry as follows: 

0000 

Indicates to the Loader that there are no more data words 
to process on this card. 



0001 



nmn 



Bitl 



means C is added. 

1 means C is subtracted. 



Indicates that the location counter is affected; the data 
word is of the following form: 

pfx a, .relative location 
where: 

pfx = PZE if a is an absolute origin. 

pfx = PON if a is the relative origin. 

pfx = PTW if BSS is of length a. 

pfx = PTH if the instruction is an EVEN pseudo- 
operation. 
The address portion a is the number of the entry in the 
control dictionary for this deck that determines whether the 
Loader should generate an AXT 0„0 instruction to force 
the next text word into an even location. 

pfx = MZE if a is a dictionary origin in complex format. 
The relative location of this instruction is as it 
appears in the listing. 

Note: Origins are an integral part of text; each card does 
not carry its relative load address. 

A CALL expansion follows; the data word is: 

PZE 

This control code and the word in this form are required 
for the overlay mechanism of the Loader. 
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0011 \ 

0100/ 

0101 ) Unused codes 

0110 \ 

0111/ 



10VV 



Relocation bits in this form indicate that the data word 
results from a VFD instruction. VV represents bit configura- 
tions indicating the kind of action the Loader must take to 
evaluate the data contained in the word. 

For each field in a VFD instruction, the Assembler gen- 
erates a word. Up to 30 bits of the data from that field are 
contained in bits 6-35 of the generated word. When there 
are more than 30 bits of data in the VFD field or there is 
more than one field listed, the data is contained in words 
that follow. As many words are generated as are needed 
to contain the data. 

For example, consider these VFD instructions and bits 
6-35 of the words generated by the Assembler: 



INSTRUCTION 

VFD H36/ABCDEF 
VFD 12/3,06/47 



DATA WORD, BITS 6-35 

2122232425 
0000000026 
0000000003 
0000000047 



The Loader must evaluate the data contained in the 
generated words and load it as a table according to speci- 
fications by the Assembler. The specifications for loading 
are contained in bits S, 1-5 of the generated words. The 
code used is: 



T 


bit count 


D 



T = if the current series of generated words con- 

tinues beyond this word. 

T = 1 if the current series terminates with this word, 

which is filled with zeros in the unused lefthand 
positions. 

N < 30 if the rightmost n bits of this word are to be 
loaded into the table. 
The specifications for evaluating the data are contained 

in the relocation bits VV associated with each generated 

word- The rode used is as follows: 



VV = 01 if D contains the relative address of a data word. 
The address is to be relocated just as in a stand- 
ard data word and is substituted for a 15-bit 
address. The rightmost n bits are then inserted 
into the VFD string to be loaded. 

VV =10 if D contains a dictionary reference. It is to be 
evaluated just as in a standard data word dic- 
tionary reference and is substituted for a 15-bit 
address. The rightmost n bits are then inserted 
into the VFD string. 

VV =11 if D is the address of a data word that is repre- 
sented by a complex expression. The Loader 
must evaluate the string of data words that fol- 
low in the same way that it evaluates complex 
expressions in standard data words. The final 
result is substituted for a 15-bit address, and 
the rightmost n bits are then inserted into the 
VFD string. 

As examples of VFD data words and the control groups 
associated with them, consider the following, where the 
relative location of A is 103, the dictionary location B is 3, 
and the size of the control dictionary is 25: 



VFD EXAMPLES 

VFD H30/ABCDE 
VFD H36/ABCDEF 



RELOCATION 

BITS 

10 00 

10 00 
10 00 



DATA WORD 

76 2122232425 
36 2122232425 
46 0000000026 



VFD EXAMPLES 

VFD 15/A, 06/47, 15/B + 2 



RELOCATION 

BITS 

10 01 

10 00 

10 11 



DATA WORD 

17 0000000103 
06 0000000047 
57 0000003002 



1100 
1110 

1111 



unused codes 



Indicates to the Loader the end of text. The address por- 
tion of the corresponding special entry word contains the 
relative location of the first instruction to be executed if 
this deck is named on a $ENTRY card. 

Control Dictionary Binary Text 

Words 3-24 of a control dictionary text card contain 
up to eleven 2-word entries. A control dictionary de- 
fines procedure and/or data areas for a deck that may 
be deleted, replaced, or referred to by other program 
segments that have been separately assembled or com- 
piled. Each entry in the control dictionary supplies an 
external reference name of a control section, its loca- 
tion relative to the origin of the deck and its length. 
If the control section is virtual, its length is entered as 0. 

The first entry is the preface entry. This is not a true 
control section entry, but gives information about the 
deck as a whole. The remaining entries refer to par- 
ticular control sections. The length of the first control 
section following the preface entry encompasses the 
entire deck. All other real control sections can be con- 
sidered as nested within this first section. 

Preface Entry Format: The preface entry contains 
the location of the first executable instruction, the deck 
length, the machine for which the deck was assembled, 
and the size of the control dictionary. The contents of 
the two words are: 



where: 



prx 
pze 



p, , mach 



first 



itable 



the relative location of the 

instruction. 

the length of the deck. 

the power of 2 that includes the number of 

entries in this control dictionary. 

if this deck was assembled for a 7090. 

if this deck was assembled for a 7094 ( may not 

run on a 7090). 

if this is a relocatable deck. 

if x is the absolute location at which this deck 

is to be loaded. 

Format for All Other Entries: Control dictionary en- 
tries other than preface entries are of the following 
format: 



n 


= 


P 


= 


mach 


= 




A 

— *± 


pfx 


= PZE 




= MON 



word 1 = BCI 
word 2 = pfx 



1, exname 
t, ,n 



where exname is the six-character alphameric external 

name of the control section. 

pfx = PZE when this section is real ( it exists in this deck ) . 
= PON when this section is an EVEN pseudo-operation; 
the length always equals 0; exname is zeros. 
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= PTW when this section is a virtual section (only refer- 
ences to the section appear ) ; exname must appear 
as a real control section in at least one other deck 
in the program (including decks from the Sub- 
routine Library). 

t = the relative location of the beginning of a control section. 
It is equal to zero if pfx is equal to PTW. 

n = the length of a control section. It may be equal to zero. 

All binary text cards for a control dictionary except 
the last are full. 

Control dictionary entries are stored in order of in- 
creasing relative location. Nested control sections hav- 
ing the same relative origin are stored in order of de- 
creasing section length. 

Debugging Dictionary Binary Text 

Words 3-24 in the binary text card in a debugging dic- 
tionary contain entries of from one to three words. 
Entries may be split between cards. Therefore, every 
card except the last must be full. 

The debugging dictionary is processed by the 
Loader. It is modified and written on sysck2 following 
any information previously written by the debugging 
compiler. All this information makes up the first file of 
SYSCK2. The debugging postprocessor uses tnis iniorrna- 
tion together with the dumps ( the second file of sysck2) 
to produce the final debugging output. 

Debugging Dictionary Text Card Format: Each en- 
try in the debugging dictionary is from one to three 
words long. Mode changes that occur at a location for 
which there is no associated symbol cause a one-word 
entry in the debugging dictionary as: 



s 1 



3-17 



18-20 



21-35 






A 


M 





M 


value 



The M bits in positions 2, 18, 19, and 20 make up a 
four-bit mode designator. A is if the value in bit 
positions 21-35 is relative, 1 if it is absolute. 

A symbol having no dimensions causes the following 
entry: 



s 


1 


2 


3-17 


18-20 


21-35 


1 


A 


M 





M 


value 


SYMBOL 



where A, M, and the value in bit positions 21-35 are as 
above, and symbol is the bcd representation of the 
symbol. 

A relative symbol having one dimension causes the 
following entry to be generated: 



s 


1 


2 


3-17 


18-20 


21-35 


1 





M 


1st dim. 


M 


value 


SYMBOL 



A relative symbol having two or three dimensions, 
or an absolute symbol having one, two, or three dimen- 
sions, results in the following entry: 



s 


1 


2 


3-17 


18-20 


21-35 




1 


1 


M 


1st dim. 


M 


value 


SYMBOL 











2nd dim. 


B 


3rd dim. 





where B is if the value in bit positions 21-35 is rela- 
tive, 1 if absolute. The 2nd ( and 3rd ) dimensions will 
be zero if not applicable. 

Even Storage Feature 

The specification of even storage for data or instruc- 
tions is accomplished by the use of the map language 
even pseudo-operation. This even pseudo-operation is 
ignored by ibmap when assembling for the 7090 or 
7094 ii. 

The even pseudo-operation causes the generation of 
an entry in the control dictionary, specifying a control 
section of zero length that has the special name of all 
zeros. 

Since each even control dictionary entry now repre- 
sents a point where an even absolute location must be 
assigned, the Loader may now expand that control 
section to length 1 if it is necessary to force an even 
location. In addition to the generation of a zero-length 
control section, the even pseudo-operation causes the 
placement of an even entry in the binary text. An even 
appearing within a control section must have the same 
relative location as the start of the control section. 

Upon encountering this text entry, the Loader gen- 
erates an axt o,o instruction if the current absolute 
location is odd. Since no reference in text can ever 
appear in the even control section, generation of the 
axt does not affect execution of the program. Since the 
axt instruction, if generated, always occupies odd 
storage, its execution is free. 

Errors may occur when the programmer forgets that 
relative locations or the length of a block of data may 
change due to the insertion of axt instructions. 

Format for an EVEN Control Dictionary Entry 

The control dictionary entry for an even pseudo- 
operation appears as: 

word 1 bci 1,000000 

2 pon r, , 

The field r is the relative location which must be as- 
signed an even absolute location. 

Format for an EVEN Relocatable Binary Text Entry 

In relocatable binary text an even pseudo-operation 
appears as : 



where 1st dim. is the dimension. 



RELOCATION BITS 
0001 



DATA WORD 

PTH b 
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The field b conforms with the 15-bit code for control 

correct even control section. 

EVEN Program Example 

An example of how the Loader deals with even pseudo- 
operations is: 



If the program origin assigned by the Loader is even, 
the second even text entr* 7 at 103 causes the "eneratioi 
of an axt instruction that moves the bss to relative 
location 104. If the origin assigned is odd, the first even 
text entry generates an axt instruction, moving the stz 
instruction to relative location 101. 



:l loc 


RELOCATION 










ORG = 10000 




ORG = 20001 


CTR 


BITS 


OCTAL 


SYMBOLIC 


10100 


60000 10026 


20101 


77400 00000 


100 


00 01 


3 00000 00004 


EVEN 




10101 


2 00001 4 10100 


20102 


60000 20027 


100 


1 00 01 


60000 00026 


STZ 


A, 4 


10102 


00000 00000 


20103 


2 00001 4 20102 




















1 I ll 


J^ Ml I 1J J^ 


Z UUUUI 4 UUIUU 


1 1A 


~-JL, 1, i. 


lUiUii 


U / ItUU U UL'UUU 


ZUiU^ 


i_i UIJIJUU u uouuu 


102 


1 00 00 


00000 00000 


HTR 





10104 


5 00000 00000 


20105 


77400 00000 


103 


00 01 


3 00000 00005 


EVEN 




10105 


5 00000 00000 


20106 


5 00000 00000 


103 


00 01 


2 00000 00002 


BSS 


2 






20107 


5 00000 00000 
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Subroutine Library Information 



The Subroutine Library consists of system subroutines, 
Fortran iv subroutines, and cobol subroutines. The 
system subroutines are used by the ibjob Processor to 
maintain control and communication among the system 
programs. The Fortran iv section of the Subroutine 
Library includes the Fortran mathematics library, the 
Fortran input/output library and the Fortran utility 
library. The cobol subroutines include subroutines 
needed for the movement, conversion, input, and out- 
put of data. 

The subroutines in the Fortran mathematics library 
and the subroutines in the Fortran utility library that 
are available to the applications programmer are de- 
scribed in the section "Subroutine Library (iblib)." 
The system subroutines, the Fortran input/output 
subroutines, the Fortran utility routines used at exe- 
cution time, and the cobol subroutines are described 
in this section. 

The Subroutine Library is stored in two files on a 
specified system library unit ( it may be the same unit as 
the Loader). The first file contains two lists and the 
control part of each subroutine. 

List 1: This is a list of all real control section names 
appearing in the Subroutine Library. Each control sec- 
tion name appearing in the list is unique. Associated 
with each entry in this list is a position in the second 
list ( dependence list ) and the name of the subroutine 
in which this control section appears. Each entry also 
contains the record number giving the position of the 
subroutine in the control information and text files. 

List 2: For each entry in the control section name 
list, the dependence list contains a table showing the 
control sections which must be loaded for execution 
of this control section. Therefore, a given control sec- 
tion is said to be dependent upon those control sections 
whose names appear in the corresponding dependence 
list portion. Multilevel dependency is allowed (that 
is, the dependent sections of each item in the depend- 
ence list are called with the original dependent sub- 
routine ) . 

Because equal names of control sections cause dele- 
tion of all but one of the control sections in the object 
program, it is possible for an object program to include 
a control section which will be used by a library sub- 
routine. This is done in the object program by specify- 
ing a control section name that is the same as the name 
which appears in the dependence list. Conversely, care 
must be taken in specifying control section names. 



both in object programs and in library subroutines, to 
avoid inadvertently causing this replacement. As a 
means of expressing dependency, this string of control 
section names is written using the following conven- 
tions: 

1. One half-word (18 bits) is used for each entry. 

2. The three high-order bits in each entry make up a 
code indicating the position of the entry in the list, 
as follows: 



000 
100 
010 



First entry in the list 
Second entry in the list 
All other entries 



3. Each dependency list contains 15-bit index refer- 
ences to the real section name list (List 1) for each 
required name. Each 15-bit index reference appears 
in either the decrement portion or the address portion 
of a word, with an operation code ( 3 bits ) preceding 
it in the prefix or tag, respectively. 

The first Library subroutine file also contains the con- 
trol dictionaries for all the subroutines. It may also 
contain Loader control cards and the file dictionaries. 
A sibldr card must precede each control dictionary. 
Any of the following control cards may appear after 
the sibldr card if a subroutine requires their use: sfile, 
slabel, spool, or sgroup cards. 

If a file dictionary is included, it must appear after 
these control cards and must be immediately preceded 
by a sfdict card. 

List 1, containing the subroutine name and its as- 
sociated record numbers, is used to locate a particular 
subroutine on tape, and is used to compute a track 
address when the Library is on disk. 

The second Subroutine Library file contains the 
relative binary text for all library subroutines. Each 
relative binary text deck is preceded by a stext card 
and followed by a sdkend card. 

The use of the above format for the Subroutine 
Library permits rapid acquistion of needed subroutines 
without multipass searching of the library unit. 

System Subroutines 

The operating system uses the following Library sub- 
routines to initialize communications regions used by 
the operating system components to transfer control 
to the object program and other system components. 
System subroutines also provide input/output support, 
overlay features, debugging facilities, and error rou- 
tines. Those subroutines marked with an asterisk are 
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loaded with each object program. The remainder of 

i.1, 1 i.: 1 ]„J —.1 3 — 3 „„ J„j- .• 3 

uio auuiuuLinca die luciucu wucn nccucu, cts uclciihijucu 

by control cards, specifications on control cards, and 
the requirements of the object program. 

SUBROUTINE DESCRIPTION 

*.IBSYS Defines the indexes of the system units and the 

location of the System Monitor (IBSYS) com- 
munication region. 

*.IOEX Defines the location of the Input/Output Execu- 

tor ( IOEX) entry points. 

*JBCON Relocates Processor Monitor communication 

words, used during object program execution, to 
an area immediately adjacent to IOEX. 

*.LXCON Closes files used by the object program, thereby 

stopping all input/output activity. The post- 
execution subroutine is required for all object 
program executions. It is normally entered at 
the end of object program execution, but it is 
also entered if execution is terminated by a 
system stop or an STR instruction. Control is 
returned to the System Monitor. 

.IBDBI Monitors STR instructions during debug execu- 

^ir»rjc ^.xici < s x' i c ii, '"* ac fi^DTif* rc^ucs^s * is rc^uirsd 
by all debug executions. This subroutine is 
loaded at a location preceding all input decks 
and subroutines not explicitly associated with 
the Debugging Processor. 

.DSTRN Searches a table of debug request points in a 

program not using overlay for .IBDBI and is 
required by all nonoverlay debug executions. 

.DSTRO Searches a table of debug request points in a 

program using overlay for .IBDBI and is re- 
quired by all overlay debug executions. 

.IODEF Contains the primary Input/Output Control 

System (IOCS) communication region. General 
entry and exit routines used by all IOCS pack- 
ages are contained in this subroutine. The actual 
communication region required for a given level 
of IOCS is initialized by .IOCSF for standard 
FORTRAN IOCS; .IOCSM for Minimum IOCS; 
.IOCSM and .IOCSB for Basic IOCS; and 
.IOCSM, .IOCSB, and .IOCSL for Label IOCS. 
Loading of this subroutine is suppressed if the 
alternate FORTRAN input/output package is 
requested. 

.IOCSF Contains the text for the special IOCS used by 

FORTRAN IV object programs if the standard 
FORTRAN input/output package is requested. 
This subroutine also initializes the communica- 
tion region required for standard FORTRAN 
IOCS. 

.IOCS Contains the text for all levels of relocatable 

IOCS. 

.IOCSM Initializes the communication region required 

for Minimum IOCS. 

.IOCSB Initializes the communication region (in addi- 

tion to that initialized by .IOCSM) required for 
Basic IOCS. 

.IOCSL Initializes the communication region (in addi- 

tion to those initialized by .IOCSM and .IOCSB) 
required for LABEL IOCS. 

•LOVRY Loads overlay links. It is required for all object 

programs using the overlay feature. 

.LXSL Initializes read and write selects, and provides 

linkage to IOEX when the alternate FORTRAN 
input/output package is requested for a FOR- 
TRAN IV object program. 



ENTRY 


.COUNT 


DEC 


n 


END 





SUBROUTINE DESCRIPTION 

*,FPTRP Determines the condition that caused the 

floating-point trap, sets appropriate registers 
accordingly, and writes a message on the system 
output unit, giving the cause of the trap and the 
octal location at which it occurred. Location 
COUNT contains the maximum number plus 
one, of times that messages will be written for 
each execution. This number is set at five plus 
one, but it can be changed by the programmer. 
The number in location COUNT, which is the 
control section .COUNT, may be changed by 
addressing this control section in a MAP lan- 



COUNT 



where n is a decimal number. Messages are 
then written n-1 times. The value set by this 
procedure applies only for one program. 

.RAND Provides for processing of random records on 

1301/2302 Disk Storage. 

Note: The Debugging Processor subroutine .ibdbi 
must 1O11OW suuroutme .lxcon in tue Subroutine Li- 
brary. The Input/Output Control System subroutines 
must be in the following order in the Library: 

.IODEF 
.IOCSF 

.iocs 

.IOCSM 

.IOCSB 

.IOCSL 



FORTRAN IV Input/Output Library 

The Fortran iv input/output library contains a group 
of subroutines used to implement the source lan^ua^e 
input/output statements. The input/output library 
contains two input/output packages. The standard 
package and the alternate package coordinate all 
binary and bcd input/output operations for a Fortran 
iv program. Both packages are specified by parameters 
on the sibjob card. The available input/output support 
for a Fortran iv program is summarized as: 



REQUEST 

ALTIO 
FIOCS 



blank 



PACKAGE USED 

Alternate 
Standard 



Standard 



input/output support 



IOEX 
FIOCS 



IOCS 



Trap Supervisor 
Modified version of the 
minimum level of IOCS 
Minimum level 

or 
Basic level 

or 

Labels level 

(The level of IOCS to be 
used is determined by the 
i Loader. ) 



Note: With the exception of altio, if the program- 
mer requires a higher level of iocs than what is speci- 
fied, the Loader automatically loads the higher level 
with the program. 
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Standard FORTRAN IV Input/Output Package 

The standard Fortran iv input/output package is one 
of two such packages in the Subroutine Library to 
coordinate input/output operations for Fortran pro- 
grams. The subroutines in this package handle inter- 
face functions, conversions, and buffer-building. Data 
is transmitted using one of the several levels of the 
Input/Output Control System (iocs). 

The interface subroutines in the standard package 
control the input/output operations that are requested 
by actual Fortran iv source program statements. A 
unique interface subroutine exists for each type of 
input/output statement. Because the interface sub- 
routines are unique, only those subroutines needed 
for the specific operation requested must be in core 
storage at execution time. These subroutines are: 



SUBROUTINE 



DESCRIPTION ENTRY POINT DESCRIPTION 



FRWT 



SUBROUTINE 

FRDD 



DESCRIPTION 

Controls reading 
of BCD records. 



ENTRY POINT 

.FRDD. 



FRDU Controls reading .FRDU. 
of BCD records. 



FWRD Controls writing .FWRD. 
of BCD records. 



FWRU Controls writing .FWRU. 

of BCD records. 



FRDB Controls reading .FRDB. 
of binary records. 



FWRB Controls writing .FWRB. 
of binary records. 



FRCD Controls on-line .FRCD. 

reading of cards 
and conversion of 
alphameric card to 
BCD. 

FPRN Controls printing .FPRN. 
by the on-line 
printer. 

FPUN Controls punching .FPUN. 
by the on-line 
punch. 



DESCRIPTION 

Entry point for 
BCD read; called 
for source program 
statement READ 
(unit, format) list. 

Entry point for 
BCD read; called 
for source program 
statement READ 
(unit, NAMELIST 
name ) . 

Entry point for 
BCD write; called 
for source program 
statement WRITE 
(unit, format) list. 

Entry point for 
BCD write; called 
for source program 
statement WRITE 
(unit, NAMELIST 
name ) . 

Entry point for 
binary read; called 
for source program 
statement READ 
(unit) list. 

Entry point for 
binary write; called 
for source program 
statement WRITE 
(unit) list. 

Entry point for 
card read; called 
for source program 
statement READ 
format, list. 

Entry point for 
source program 
statement PRINT 
format, list. 

Entry point for 
source program 
statement PUNCH 
format, list. 



FEFT 



FBST 



.FRWT. Entry point for the 
source program 
statement RE- 
WIND unit. 

.FEFT. Entry point for the 
source program 
statement END 
FILE unit. 

.FBST. Entry point for the 
source program 
statement BACK- 
SPACE unit. 

The buffer-building subroutines (fcnv, fiob, fioh, 
and fios) control the conversion and movement of 
data into and out of the buffers. These subroutines are 
identical for both Fortran iv input/output packages 
and are described in the following list of miscellaneous 
subroutines. The remainder of the subroutines de- 
scribed are needed to implement the input/output 
statements. 



Rewinds desig- 
nated unit. 



Writes a file mark 
on the designated 
unit. 

Backspaces the 
designated unit 
one record. 



SUBROUTINE 

FCNV 



FIOB 



DESCRIPTION 

Performs all nec- 
essary conversions 
for input and out- 
put list items. 1 

Processes list items 
for binary trans- 
mission. 



FIOH 



Scans FORMAT 
statements and 
links to the object 
program to begin 
conversion of data. 



ENTRY POINT DESCRIPTION 

.FCNV. Entry point for 
input and output 
list. 

.FIOB. Entry point for 

binary transmision 
routines. 

.FBLT. Entry point for 
single-precision 
binary input/ 
output list. 

.FBDT. Entry point for 
double-precision 
binary input/ 
output list. 

.FRLR. Entry point for 
end of list for 
binary input. 

.FWLR. Entry point for end 
of list for binary 
output. 

.FIOH. Entry point for 

BCD transmission 
routines. 



FIOS 



Initializes all 
input/output li- 
brary IOCS calling 
sequences for bi- 
nary and BCD 
transmission. 



.FRTN. Entry point for end 

of list for BCD 

input. 
.FFIL. Entry point for end 

of list for BCD 

output. 

.FIOS. Entry point for all 
input/output inter- 
face routines. 



.FSEL. Entry point for 
BCD or binary 
read. 

.FRTD. Entry point for 
BCD write. 



Conversions performed on source program input data and 
object program input data give the same result. 
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SUBROUTINE 



DESCRIPTION ENTRY POINT 



FSLBI 



FSLDI 



.FILR. 



.FILL. 



.FCLS. 



.TOUT. 



FIOU Controls process- 
ing of lists of var- 
iables and arrays 
associated with a 

XT A \ JTPT TOT" 

i\AiviHii_ij.o l name 
for BCD input. 

FOUT Writes blocked 

records on the sys- 
tem output unit. 



FSLBO Controls processing 
of lists containing 
nonsubscripted 
binary array names 
for output. 



Controls processing 
of lists containing 
nonsubscripted 
binary array names 
for input. 



Controls processing 
of lists containing 
nonsubscripted 
BCD array names 
for input. 



.FIOU. 



.FOUT. 



.FBLO. 



.FBDO. 



.FBLI. 



.FBDI. 



.FSLI. 



.FSDI. 



DESCRIPTION 

binary write. 
Entry point to 
initialize input/ 
output command 
for reading. 
Entry point to 
initialize input/ 
output command 
for writing. 
Entry point to 
close a file. 
uiiuV point lO 
open a file. 
Entry point at 
which the call to 
entry point .FOUT. 
is loaded if subrou- 
tine UN06 is used 
by object program. 
Entry point for in- 
put of BCD var- 
iables and arrays 
referred to by a 
NAMELIST name; 
called by FRDU. 

Entry point for 
subroutine FOUT. 
If subroutine 
FOUT is loaded 
with an object pro- 
gram, the calls to 
entry point 
.LXSEL in sub- 
routines .LXCON, 
.FPTRP, and 
FXEM are over- 
laid by a call to 
subroutine FOUT. 

Entry point for 
output of non- 
subscripted binary 



arrax/c nnnc 



single-precision or 
complex data. 
Entry point for 
output of nonsub- 
scripted double- 
precision binary 
arrays. 

Entry point for in- 
put of nonsub- 
scripted binary 
arrays consisting of 
single-precision or 
complex data. 
Entry point for 
input of nonsub- 
scripted double- 
precision binary 
arrays. 

Entry point for 
input of nonsub- 
scripted BCD 
arrays consisting of 
single-precision or 
complex data. 
Entry point for 
input of nonsub- 
scripted double- 



SUBROUTINE DESCRIPTION ENTRY POINT DESCRIPTION 

precision BCD 
arrays. 



FSLDO 



Controls processing .FSLO. 
of lists containing 
nonsubscripted 
BCD array names 
for output. 

.FSDO. 



FSLI 



Sets up indexing 
for input to non- 
subscripted arrays. 



.SLI. 



.SLI1. 



.SDL 



.SDIL 



FSLO 



Sets up indexing 
for output of non- 
subscripted arrays. 



.SLO. 



.SLOl. 



.SDO. 



.SDOL 



FVIO 



Establishes identi- 
fication between a 
variable logical 
unit and the cor- 



.FVIO. 



Entry point for 
output of nonsub- 
scripted BCD 
arrays consisting of 
single-precision or 
complex data. 
Entry point for 
output of nonsub- 
scripted double- 
precision BCD 
arrays. 

Entry point for 
input of single- 
precision arrays. 
Set by subroutine 
FSLDI or FSLBI 
to contain appro- 
priate entry point 
to subroutine 
FRWD or FRWB, 
depending upon 
whether a single- 
precision array is 
BCD or binary. 
Entry point for 
input of double- 
precision arrays. 
Set by subroutine 
FSLDI or FSLBI 
to contain appro- 
priate entry point 
to subroutine 
FRWD or FRWB, 
depending upon 
whether a double- 
precision array is 
BCD or binary. 

Entry point for 
output of single- 
precision arrays. 
Set bv subroutine 
FSLDO or FSLBO 
to contain appro- 
priate entry point 
to subroutine 
FRWD or FRWB, 
depending upon 
whether a single- 
precision array is 
BCD or binary. 
Entry for output of 
double-precision 
array. 

Set by subroutine 
FSLDO or FSLBO 
to contain appro- 
priate entry point 
to subroutine 
FRWD or FRWB, 
depending upon 
whether a double- 
precision array is 
BCD or binary. 

Entry point called 
for any FORTRAN 
input/output 
source statement 
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SUBROUTINE 



DESCRIPTION ENTRY POINT DESCRIPTION 



responding 
FORTRAN file. 
FWRO Controls processing 
of lists of variables 
and arrays asso- 
ciated with BCD 
output. 



.FWRO. 



that specifies a 
variable unit. 
Entry point for 
output of BCD 
variables and 
arrays referred to 
by a NAMELIST 
name; called by 
FWRU. 



Note: The 7094 user can choose between two fcnv 
routines: the standard routine and the optional routine. 
Appendix E describes how to specify the desired ver- 
sion. The differences between the two versions are: 

1. The optional routine is generally faster. 

2. The handling of output data for the optional rou- 
tine differs from the standard as follows : 

a. If an output number that has been converted 
by E-, D-, F-, or I- conversion requires more 
space than is allowed by the field width w, 
the number is disregarded and the field is filled 
with asterisks. If the number requires fewer 
than w spaces, the leftmost spaces are filled 
with blanks. 

b. For output with E-conversion, if the specifica- 
tion nPEw.d requires n + d decimal digits (where 
n + d is greater than 8) n + d — 8 zeros are ap- 
pended as the low-order digits. 

c. For output with D-conversion, if the format 
specification nPDw.d requires n + d decimal 
digits (where n + d is greater than 16), n+d 
— 16 zeros are appended as the low-order digits. 



Alternate FORTRAN iV Input/Output Package 

The alternate package consists of a group of Library 
subroutines that coordinate binary and bcd input/ 
output operations for Fortran iv programs. These sub- 
routines use the Input/Output Executor (ioex) to 
supervise trapping operations. Because the iocs rou- 
tines are not used, the locations previously used by the 
standard package for the required level of iocs are 
available to the object program. In addition, the loca- 
tions used by iocs for buffers are available because the 
alternate package supplies the necessary buffers. 

When the alternate package is requested, the entry 
points in the calling sequences generated during com- 
pilation are the entry points for the subroutines in the 
standard package. The Loader automatically substi- 
tutes the entry points for the necessary subroutines in 
the alternate package when the program is loaded. The 
standard package entry points and the corresponding 
alternate package entry points are: 



STANDARD PACKAGE 


ALTERNATE PACKAGE 


.FRDD. 


..FRDD 


.FRDU. 


..FRDU 


.FWRD. 


..FWRD 


.FWRU. 


..FWRU 


.FRDB. 


..FRDB 


.FWRB. 


..FWRB 


.FRWT. 


..FRWT 


.FEFT. 


..FEFT 


.FBST. 


..FBST 


.FIOS. 


..FIOS 


.UN06. 


..UN06 


.FVIO. 


..FVIO 



Unit Definition and Input Files 

The alternate package is compatible with the standard 
package in respect to data language specifications and 
unit definition by file pseudo-operations. However, if 
disk or Hypertape is specified in the file pseudo-oper- 
ations when the alternate package is requested, an 
irrecoverable error results and the job is terminated. 

The input data files supplied for an object program 
using the alternate package may be in binary mode, 
bcd mode, or a combination of both modes. Output 
from a Fortran iv program using the alternate package 
may be in binary mode, unblocked bcd mode, or a com- 
bination of both modes. However, the alternate pack- 
age does not provide a look-ahead feature to facilitate 
reading of files with mixed mode. Therefore, the stand- 
ard package cannot process mixed mode files that were 
written by the alternate package. 

Over/ay Compatibility 

Since the alternate package is compatible with the 
overlay feature, overlay may be used in a Fortran iv 
program to load the necessary subroutines from the 
alternate package. These input/output support routines 
may reside in the lower level links of an overlay job, 
thereby increasing the storage space available for the 
object program. When running a Fortran rv overlay 
job, the necessary subroutines are loaded by means of 
a generated call pseudo-operation, which forces over- 
lay of subroutines already in core storage. More infor- 
mation concerning the use of the overlay feature can 
be found in the section "The Loader (ibldr)." 

Subroutines 

The subroutines in the alternate package handle inter- 
face functions and data transmission. The alternate 
package uses the buffer-building subroutines fcnv, 
fiob, and fioh in the standard package. The buffer- 
building subroutines handle conversion and movement 
of data into and out of the buffers. These subroutines 
are described under "Standard Fortran iv Input/ 
Output Package." 

The interface subroutines control the input/output 
operations requested by actual Fortran iv source pro- 
gram statements. A unique interface subroutine exists 
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for each type of input/output statement. Because the 
subroutines are individual, omy mose subroutines 
needed for the requested operation must be in core 
storage at execution time. The interface subroutines in 
the alternate package are: 



SUBROUTINE 
DECKNAME 

FRDD. 



FRDU. 



FWRD. 



FWRU. 



FRDB. 



FWRB. 



FEFT. 



FRWT. 



FBST. 



DESCRIPTION ENTRY POINT DESCRIPTION 

Controls reading of ..FRDD Entry point for 
BCD records. BCD read; sub- 

stituted at load 
time for source 
program statement 
READ (unit, for- 
mat) list. 
.FRDU Entry point for 
BCD read; sub- 
stituted at load 
time for source 
program statement 
READ (unit, 
NAMELISTname). 
..FWRD Entry point for 
BCD write; sub- 
stituted at load 
time for source 
program statement 
WRITE (unit, 
format) list. 
.FWRU Entry point for 
BCD write; sub- 
stituted at load 
time for source 
program statement 
WRITE (unit, 
NAMELISTname). 

..FRDB Entry point for 
binary read; sub- 
stituted at load 
time for source 
program statement 
READ (unit) list. 

..FWRB Entry point for 
binary write; sub- 
stituted at load 
time for source 
program statement 
WRITE (unit) list. 

..FEFT Entry point sub- 
stituted at load 
time for source 
program statement 
END FILE unit. 



Controls reading of 
BCD records. 



Controls writing of 
BCD records. 



Controls writing of 
BCD records. 



Controls reading 
of binary records. 



Controls writing 
of binary records. 



End-of-file routine 
using IOEX. 



Rewinds tape using 
IOEX. 



Backspaces tape 
using IOEX. 



..FRWT Entry point sub- 
stituted at load 
time for source 
program statement 
REWIND unit. 

..FBST Entry point sub- 
stituted at load 
time for source 
program statement 
BACKSPACE unit. 



The alternate package also contains subroutines to 
perform input/output initialization, read/write selects, 
definition of output unit, and identification of logical 
units. The subroutines used by the alternate package 
to perform these functions are: 



SUBROUTINE 
DECKNAME 

FIOS. 



FBCD. 



DESCRIPTION 

Initializes all 
input/output IOEX 
calling sequences. 

Contains BCD 
buffer and per- 
forms all BCD 
initialization. 



FBIN. 



Contains binary 
buffers and per- 
forms all binary 
initialization. 



ENTRY POINT DESCRIPTION 

..FIOS Entry point for all 
alternate interface 
subroutines. 

.FBCD Entry point for a 
BCD read request; 
used with ..FIOS. 

..FBCW Entry point for a 

BCD write request; 

used with ..FIOS. 
.FBCD Entry point for 

location of BCD 

buffer. 

..FBID Entry point for 
binary read re- 
quest; used with 
..FIOS. 

..FBIN Entry point for 
binary write re- 
quest; used with 
..FIOS. 

.FBIB Entry point for 

location of primary 



UNIT06 



FVIO. 



Defines the tape 
output unit and 
prevents loading 
of FOUT. 

Establishes identi- 
fication between 
variable logical 
unit and the cor- 
rect FORTRAN 
file; also prevents 
loading of FOUT. 



.UN06 



.FVTO 



Entry point for the 
subroutine to write 
on the system out- 
put unit. 

Entry point for any 
input/output 
source statement 
that specifies a 
variable unit. 



Note: In addition to performing specific input/ 
output operations, two of the subroutines also inhibit 
the loading of a special subroutine (fout) used by 
the standard package. Subroutine fout is loaded by 
the standard package whenever the system output unit 
is to be used for output. When used, fout forces the 
use of the iocs routines. For this reason, the loading of 
fout is prevented whenever the alternate package is 
used. 

The alternate package uses the Library subroutine 
.lxsl for transmission and linkage to ioex. This sub- 
routine is not contained in the alternate package, but 
is loaded by both the standard and alternate packages. 

Correspondence Between FORTRAN Symbolic Units 
and System Files 

The input/output devices used in data transmission are 
always referred to symbolically in Fortran iv input/ 
output statements. Object program input/output op- 
erations are handled by the standard package or the 
alternate package buffering routines and one of the 
levels of iocs. The relationship between the symbolic 
unit and the system file is shown in Figure 53. The 
normal input/output configuration contains eight sym- 
bolic units. 
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FORTRAN 

Symbolic 

Unit 


System File 


Mode 


Function 


Standard 
Package 


Alternate 
Package 


01 


SYSUT1 


Binary 


Binary 
or BCD 


Input or output 


02 


SYSUT2 


Binary 


Binary 
or BCD 


Input or output 


03 


SYSUT3 


Binary 


Binary 
or BCD 


Input or output 


04 


SYSUT4 


Binary 


Binary 
or BCD 


Input or output 


05 


SYSIN1 


BCD 


BCD 


Input 


06 


SYSOU1 


BCD 


BCD 


Output 


07 


SYSPP1 


Binary 


Binary 


Output 


08 


System 

Availability 

Chain 


BCD 


BCD 


Input or output 



Figure 53. Correspondence between FORTRAN Symbolic Units 
and System Files 

The standard package contains eight file subroutines 
named unoi, uno2, unos, uno4, unos, uno6, uno7, and 
UN08. These subroutines correspond to the eight 
Fortran symbolic units and produce the $file cards 
used by the Loader to set up file specifications for each 
file. The file subroutines arp in thp form- 



.UNxx. 
UNITxx 



ENTRY 

PZE 

FILE 



.UNxx. 

UNITxx 
specifications 



where xx is the two-digit Fortran symbolic unit num- 
ber, and the file specifications are as follows: 

unitOI file , utI, ready, inout, blk = 256, bin, nolist 

unit02 file , ut2, ready, inout, blk = 256, bin, nolist 

unit03 file , ut3, ready, inout, blk = 256, bin, nolist 

unit04 file , ut4, ready, inout, blk = 256, bin, nolist 

unit05 file , in, ready, input, BLK = 14, MULTIREEL, BCD, NOLIST 

UNIT06 FILE , OU, READY, OUTPUT, BLK = 110, MULTIREEL, BCD, 

NOLIST 
UNIT07 FILE , PP, READY, OUTPUT, BLK = 28, MULTIREEL, BIN, 

NOLIST 
UNIT08 FILE „ MOUNT, INOUT, BLK = 22, BCD 

Subroutine UN06 contains the additional entry point 
.bufsz in the form 

.BUFSZ 
BUFSIZ 



PZE BUFSIZ 

EQU 22 

where bufsez contains the maximum bcd logical record 



size. 



The use of a library subroutine of this form produces 
the sfile cards used by the Loader to establish cor- 
respondence between Fortran logical unit xx and the 
associated system file. The file specifications listed pre- 
viously are the standard Fortran file specifications for 
all system files. Since the density is not specified, high 
density is assumed. If another system unit is later as- 
signed to a file, the file specifications for the system 
unit function override the density and file-closing speci- 
fications set by the generated sfile card. 

Although all specifications for the input/output units 
are standard for Fortran iv, the file specifications for 



any unit may be altered. The Library file subroutine 
is reassembled, substituting the desired specifications 
in the variable field of the file pseudo-operation. ( The 
publication IBM 7090/7094 IBSYS Operating System: 
Macro Assembly Program (MAP) Language, Form 
C28-6392, describes the use of the file pseudo- 
operation. ) 

Reassembly of the library subroutine produces a 
sfile card with the new file specifications, enabling the 
Loader to establish a corresponding file with these 
specifications. Symbolic location .unxx. is entered into 
the control dictionary as an external symbol by the 
entry pseudo-operation. File unitxx is entered into the 
file dictionary for this Library subroutine. Because of 
the file pseudo-operation, whenever unitxx appears 
in the variable field of any instruction, the relocatable 
reference is to the file dictionary entry for file unitxx. 
The generated sfile card establishes the correspond- 
ence between file unitxx and the related system unit. 
The file specifications are those in the variable field of 
the file pseudo-operation. At execution time, the ad- 
dress field of symbolic location .unxx. is set by the 
Loader as the absolute address of the file control block 
of the corresponding unit. 

Subroutine Library Listing Output 

The loading of file subroutine UN06 forces subroutine 
fwrd to use subroutine fout when the system output 
unit is written on. Subroutine fwrd must precede sub- 
routine UN06 in the Subroutine Library, enabling fwrd 
to call subroutine fout. 

Subroutine fout generates two types of output. The 
status of bit 2 in the word at location .fdpos determines 
the type of output to be generated. When bit 2 contains 
a 1, the output is in bcd mode, blocked up to five 
lines per block. When bit 2 contains a 0, the output is 
in binary mode. The blocking factor, i.e., the number of 
logical records per block, is a function of the buffer size 
and maximum record size specified in subroutine UN06. 
The first word of each binary output block is a block 
control word. This word contains (76xxxxxxxxxx) 8 , 
where x . . . x is the number of records contained in 
the block. The first word of each record within the 
block is a record control word. This word contains 
(5xxxxx200460) 8 , where xxxxx is the number of charac- 
ters in the logical record. 

If output is to be printed on the ibm 720 Printer or 
listed off-line by a 1401 utility program that simulates 
this type of output, the file specification for file unito6 
must be 

UNIT06 FILE ,OU, READY, OUTPUT, BLK = 110, MULTIREEL, BCD, NOLIST 

When the ibm 720 Printer is used for output, the 
following change must be made in the fcnv subroutine 
LIMIT EQU 20 
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Note: When using the optional 7094 conversion routine Library Error Messages." Normally, when 

an error occurs, execution is terminate^ and. control is 



erasable locations 


E.3.E.4 


used by object 


used by object 




program. 


program. 






Provides four 


C.l 


Erasable words 


constants for 


C.2 


used by 


FORTRAN IV 


C.3 


FORTRAN IV 


Compiler use. 


C.4 


Compiler. 



routine, the cnange is 

LIMIT EQU 21 
The maximum size of bcd logical records specified 
in .bufsz must be changed to 20. 

If the contents of the system output unit are to be 
printed using the ibm 1401 Peripheral Input/Output 
Program, the file subroutine unog must contain the fol- 
lowing file specifications: 

UNIT06 file ,ou, ready, output, blk = 116, MULTIREEL, BIX, NOLIST 

FORTRAN IV Utility Library 

The utility library contains subroutines used by the 
Fortran iv Compiler to restore information destroyed 
by the object program, perform error diagnostics, aid 
the translation of Fortran iv into Fortran ii, and re- 
turn control to the operating system. These subroutines 
are described as follows: 

SUBROUTINE DESCRIPTION ENTRY POINT DESCRIPTION 

.ERAS. Provides four E.1,E.2, Erasable words 



.xcc. 



FPARST Used to determine PART Entry point to de- 
for FORTRAN IV, termine address or 

address of desired quantity to be 

part of double- obtained, 

precision or com- 
plex pair, as speci- STORE Entry point for 
fied in FORTRAN obtaining address 

II program. into which a quan- 

tity is to be stored. 
FXEM Controls object .FXEM. Entry point for 

program error pro- execution error 

cedure. diagnostics. 

.FXOUT Entry point at 

which the call to 
entry point 
.LXSEL is overlaid 
by a call to subrou- 
tine FOUT if 
FOUT is loaded 
with an object 
program. 
.FXARG Parameter for the 
call to subroutine 
XIT Returns control to FOUT. 

subroutine EXIT Entry point for 

.LXCON. ending program 

execution. 

The utility library also contains some subroutines 
available for use in a Fortran iv program. These sub- 
routines are described in the section "Subroutine Li- 
brary (iblib)." 

The utility subroutine fxem is called when an object 
program error is found by the Subroutine Library, and 
an error message is written on the system output unit. 
The error messages are described in the section "Sub- 



given to subroutine .lxcon to return control to the op- 
erating system. However, some subroutines have op- 
tional exits that allow execution to continue. 

These optional exits are controlled by bits in loca- 
tions optwdi, optwd2, and optwd3. These bits corre- 
spond to error codes listed with the error messages and 
the optional exits. Error codes 1-35 are controlled by 
bits 1-35 of optwdi; codes 36-70 are controlled by bits 



rt\7 nirv 



1-7 of OPTWD3. To use an optional exit, the bit asso- 
ciated with the relevant error code must be set to 1. A 
control section in subroutine fxem sets to 1 each bit 
relevant to an optional exit enabling use of all permis- 
sible exits. The control section used is: 

ENTRY .OPTW. 

.OPTW. OCT 377777777740 

DEC 

OCT 376000000000 
END 

In the distributed version of the Subroutine Library, 
the bits for error codes 1-30 and 71-77 are set to 1 for 
the use of optional exits. If the optional exits are not 
to be used, the appropriate bits may be set to zero by 
changing locations optwdi, optwd2, or optwds. These 
locations are the three octal words in the .optw. con- 
trol section. The exits set by changing these locations 
apply only for one application. The use of optional exits 
may be made standard by reassembling subroutine 
fxem with the bits set as desired. 

In addition to the error conditions found by the 
Subroutine Library, an object program calls subroutine 
fxem when an invalid value for a computed go to 
statement is found. This error condition has the error 
code 55 and has no optional exit. If subroutine fxem 
is called by a programmer-designed routine and a 
nonstandard error code argument is used, the error 
code is written on the system output unit, execution is 
terminated, and control is given to subroutine .lxcon. 

An error-flow trace is given each time subroutine 
fxem is called. The trace lists the sequence of calls, 
in reverse order, through any number of levels of sub- 
programs out of the main program. 

Three pieces of information are given for every call 
statement in the sequence: the name of the routine in 
which the call statement occurs; the absolute location 
of the call in core storage; and the line or identifica- 
tion number of the call statement as it appears in a 
listing of the given routine. 

A complete error-flow trace is not possible in a map 
routine if a call is made to an entry point within the 
same routine. This cannot occur in a routine written in 
the Fortran language or in a subroutine in the Sub- 
routine Librarv. 
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COBOL Subroutines 

The Subroutine Library contains a group of subrou- 
tines used by cobol object programs. The cobol Com- 
piler generates the instructions needed to call the 
appropriate subroutine. The Loader completes the ob- 
ject program by loading the necessary subroutines and 
inserting the addresses assigned to the subroutines into 
any instructions referring to the subroutines. 

cobol object programs most frequently use the 
movpak subroutines, which move, convert, and edit 
data. Another group of cobol subroutines in the Sub- 
routine Library coordinate input/output operations. A 
third group of subroutines perform arithmetic opera- 
tions, additional conversion, and comparison of alpha- 
betic fields. A fourth set of subroutines provide acpess 
to fobtran mathematical subroutines from a cobol 
program. 

MOVPAK Subroutines 

The movpak Subroutines move data from a source field 
to a receiving field, performing necessary conversions 
and editing operations. The subroutine used to perform 
the necessary operation depends on the data in the 
source field and the type of data desired in the receiv- 
ing field. 

These subroutines use four special locations to store 
information. The movpak subroutines are usually called 
by one of four major entry points and then by another 
call to one of the special subroutines to perform the 
move. 

MOVPAK Subroutine Special Locations 

The movpak subroutines use four special locations to 
retain information while the subroutines are executed. 
Two of these locations indicate the position in storage 
of the data involved in the move. The other two loca- 
tions indicate certain conditions that may result when 
the subroutines are executed. 

Location .caref indicates the source field of the data 
to be moved, .caref contains 

PZE location„byte 
where location is the address of the first word of the 
source field involved in the move. However, since a 
source field may begin with part of a word, the first 
byte position of the source field must also be indicated. 
The value for byte may be 0, 1, 2, 3, 4, or 5, depending 
on the byte that begins the source field. Since a byte is 
defined as six consecutive bits, byte position is bits S 
through 5 of a word in storage, byte position 1 is bits 
6 through 11, etc. 

Location .cbref indicates the receiving field of the 
data to be moved, .cbref contains 

PZE location„byte 



where location is the address of the first word of the 
receiving field and byte the first byte position involved 
in the move. The byte position for the receiving field 
is not required to coincide with the byte position for 
the source field. 

Location .coflo is set to nonzero whenever any one 
of the numeric move or convert movpak subroutines 
detects the truncation of significant high-order digits. 
.coflo contains 

PZE ** 

The location is tested by generated instructions to 
determine if a size error has occurred. If a size error 
has occurred, a message is written indicating that sig- 
nificant digits were truncated, and execution of the 
program continues. 

Location .cuflo is set to nonzero whenever a float- 
ing-point underflow results from a move operation. 
.cuflo contains 

PZE ** 

At present, no generated instructions test the status 
of this location. 

Note: The floating-point trap routine also indicates 
occurrences of floating underflow and overflow. (See 
tne uescription oi .fftrf in oystern oUuroutines. / 

MOVPAK Major Entry Points 

The movpak subroutines are called by using one of 
four major entry points. The entry point used depends 
on the number of address reference words that must be 
set up. These words, if used, follow the call to the entry 
point and indicate the position of data in storage. The 
information contained in the address reference words 
is used to set locations .caref and .cbref. 

If both a source address reference word and a re- 
ceiving address reference word must be set up, entry 
point .cmpak is used. The call to this subroutine is 
generated as: 

TSX .CMPAK,4 

source address reference word 
receiving address reference word 
( begin specific move call ) 

This entry uses the address reference words to set 
the contents of locations .caref and .cbref. Control is 
then transferred by a specific move call to the subrou- 
tine that performs the move. The move call used de- 
pends on the type of data used. These move calls are 
described in the section "movpak Subroutine Calls." 

If the source field is an arithmetic register or if no 
source field is needed, entry point .cmpki is used. The 
following coding is generated to call this entry point: 

TSX .CMPK1,4 

receiving address reference word 
( begin specific move call ) 

If the information that results from a conversion or 
edit operation is to remain in an arithmetic register, 
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entry point .cmpk2 is used. The following coding is 

used: 

TSX .CMPK2,4 

source address reference word 
( begin specific move call ) 

If no address reference words are needed, the follow- 
ing call to entry point .cmpk.3 is used: 

TSX .CMPK3 

(begin specific move call) 

This entry is used when the source field is in an arith- 
metic register and the result is to be left in an arithme- 
tic register. Entry point .cmpk3 is also used when any 
necessary address references have been previously 
stored in locations .caref or .cbref. 

Address Reference Words 

A call to any movpak entry point except .cmpk3 is 
followed by one or more address reference words. The 
address reference words are in one of three forms, de- 
pending on the location of the data. 

If the data is in working storage, the following cod- 
ing is used: 

PZE location„byte 
where location is the address of the first word of the 
field involved in the move, and byte is the first byte 
position of the field involved. 

If the data is in an iocs buffer, the following coding 
is used for the address reference word: 

MZE BL + nnn„SP + nnn 
where BL + nnn is the base locator reference and sp + nnn 
is the displacement from the base. A base locator 
locates the first word of data in an iocs buffer. The 
displacement of the data from the base is a constant. 



T^, 
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of the constant, and the byte-displacement, if any, is 
in the decrement. 

If the data is subscripted items in either working stor- 
age or an iocs buffer, the following coding for the ad- 
dress reference is used: 

MON PI + nnn 
where Pi + nnn indicates the position of the data within 
the storage area. The positional indicator is calculated 
at execution time. 

MOVPAK Subroutine Calls 

After the call has been made to one of the four entry 
points of the movpak subroutines, another call transfers 
control to a specific subroutine within movpak. Usually, 
a tsx instruction transfers control to the entry point 
and a txi instruction transfers control to the specific 
subroutine; specific exceptions will be noted in the 
following discussion. Although most movpak sub- 
routines may be called by any one of the four major 
entry points, subroutine .cexam is only called by cmpk2. 



This subroutine processes text strings created by the 
examine and if (class) analyzers. The calling se- 
quence for this subroutine is: 

TSX .CMPK2,4 
address reference word 
TXI entpt,l,n 

where the address reference word corresponds to the 
description in the section "Address Reference Words" 
and entpt is one of the following entry points: 

.CEXAM for true EXAMINE statements 
.CXAMA for IF....ALPHABETIC statements 
.CXAMN for IF.. ..NUMERIC statements 

and n is the length of the address reference word. 

The following abbreviations are used in the discus- 
sions of the calls to the subroutines: 

AA Alphabetic field (The PICTURE clause contains only 

A's.) 
AN Alphanumeric field ( The group item or PICTURE clause 

contains X's. ) 
CH Characters (This category includes ALL, QUOTE and 

HIGH-VALUE figurative constants. ) 
FP Floating point (floating-point binary) 
ID Internal decimal (fixed-point binary, synchronized right) 
IN Internal decimal not SYNCHRONIZED RIGHT 
RP Report field (The PICTURE clause contains editing 

characters. ) 
SD Scientific decimal ( floating-point BCD ) 
SP SPACE (figurative constant) 
XD External decimal ( fixed-point BCD ) 
ZE ZERO (figurative constant) 

The first two letters in the description of each type of 
move represent the type of data in the source field; the 
last two letters represent the type of data in the re- 
ceiving field. For example, the move from internal 
decimal to external decimal is designated by the letters 

IDXD. 

Literals are classified as alphanumeric, numeric, or 
floating point, as appropriate. 

Those combinations of moves shown on the following 
pages that are legal are listed in the description of the 
move verb in the cobol manual. 

AAAA, AAAN, AN A A, AN AN 

Most moves of simple bcd alphanumeric or alphabetic 
fields are handled by generated in-line instructions if 
the fields are short. Other cases are handled by calls 
to one of several subroutines depending on the data. 
If an alphabetic or alphanumeric field is to be moved 
to another field that is also alphabetic or alphanumeric, 
the following call is used: 

TXI .CANAl,l,number 
where number is the number of characters to be moved. 
If the move involves the same type of data as de- 
scribed above, but also requires additional blank char- 
acters, the following sequence of calls is used: 
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TXI .CANA2,l,numberl 
TXI .CANA3,l,number2 

where numberl is the number of characters to be 
moved, and number2 is the number of additional blank 
spaces to be inserted. 

If the move involves alphabetic or alphanumeric 
information, and the initial byte position or word length 
of the source and/or target field is not known at com- 
pilation time, the following call is used: 

TXI .CANA4,l,decrement 
PZE controll,control2 

where decrement defines the nature of controll and 
control2 as follows: 

DECREMENT VALUE EXPLANATION 

1 Control2 contains the length of the receiv- 
ing field in words. 

2 Controll contains the length of the source 
field in words. 

4 Control2 contains the address of the loca- 

tion containing the word length of the re- 
ceiving field. 

8 Controll contains the address of the location 

containing the word length of the source 
field. 

These conditions may exist in combination, giving the 
decrement a maximum value of 15. 

CHAN 

If characters are moved to an alphanumeric field, the 
following calling sequence is used: 

TXI .CHCAN,l,number 
OCT characters 

where number is the number of characters to be in- 
serted and characters is six characters of the type to be 
inserted. 

FPAN 

A move of a floating point item to an alphanumeric 
field is handled in the same manner as an alphanumeric 
or alphabetic move. The calling sequence used depends 
on the conditions described in the description of alpha- 
betic moves ( aaaa ) . 

FPFP 

A move involving floating point information is handled 
by generated in-line instructions. The movpak sub- 
routines are not used. 

FPID 

If a single-precision floating point item is to be con- 
verted to internal decimal, the following calling se- 
quence is used: 

TSX .CF1ID,4 
receiving field control word 

where the receiving field control word contains the 
following information: 



prefix PZE if the scaling factor to be used is positive; 

MZE if the scaling factor to be used is negative. 

address contains the scaling factor applied in the PIC- 

TURE clause of the internal decimal item. 

decrement contains the number of nines in the PICTURE 
clause of the internal decimal item. If the number 
of nines exceeds 10, the data is treated as double- 
precision data. 

If double-precision data is used, the following calling 

sequence is used: 

TSX .CF2ID,4 
receiving field control word 

where the receiving field control word contains the 
same information as described for single-precision data. 
Subroutine .cfhd (or .cfsid) converts the floating- 
point number in the ac to an internal decimal number 
and leaves the result in the ac (or the ac-mq). The 
calling sequence for these subroutines is a direct entry 
to movpak and is not preceded by a tsx instruction to 
one of the four movpak entry points. 

FPIN 

A conversion from floating point to internal decimal 
not synchronized right involves several intermediate 
steps. The floating point item is converted to. internal 
decimal ( fpid ) and the resulting internal decimal item 
is converted to an internal decimal item with the same 
scaling factor as the desired result ( idid ) . The follow- 
ing calling sequence is then used to complete the con- 
version to an internal decimal item not synchronized 
right: 

TXI .CIDIN,l,number 
where number is the character length of the receiving 
field, i.e., the least multiple of six bits needed to con- 
tain the desired internal decimal field and its sign. 

FPRP 

If a floating point item is to be moved to a report field, 
the data is first converted to internal decimal (fpid) 
and then moved to the report field. The calling se- 
quence used is given in the description of a move from 
internal decimal to a report field (idrp). 

FPSD 

If a single-precision floating point item is to be con- 
verted to scientific decimal, the following calling 
sequence is used: 

TXI .CF1SD,1,0 
receiving field control word 

where the receiving field control word contains the 
following information about the picture clause of the 
scientific decimal item: 

prefix PZE if no decimal point appears in the PICTURE 

clause; MZE if a decimal point appears in the 
PICTURE clause. 

address contains the scaling factor applied to the mantissa 

in the PICTURE clause. 
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tag if the mantissa is negative and the exponent is 

negative; 1 if the mantissa is negative and the ex- 
ponent is positive - 2 if the mantissa is positive and 
the exponent is negative; 3 if the mantissa is posi- 
tive and the exponent is positive. 

decrement contains the total length of the receiving field in 
characters. 

If the data is double-precision, the following calling 
sequence is used: 

TXI .CF2SD,1,0 
receiving field control word 

where the receiving field control word contains the 
same information as described for single-precision data. 
Subroutine .cfisd (or .cf2sd) converts the floating- 
point number in the ac ( or ac-mq ) to scientific decimal 
as specified in the picture clause. 

FPXD 

A conversion from floating point to external decimal 
involves an intermediate conversion of floating point 
to internal decimal (fpid). The conversion is then 
completed as described for conversion from internal 
decimal to external decimal ( idxd ) . 

IDAN 

A move of an internal decimal item to an alphanumeric 
field is handled as described for a conversion from 
internal decimal to external decimal ( idxd ) . 

IDFP 

If a single-precision floating point item is to be con- 
verted to floating point, the following calling sequence 
is used: 

TSX .CIDF1,4 

source field control word 

where the source field control word contains the follow- 
ing information: 

prefix PZE if the scaling factor is positive; MZE if the 

scaling factor is negative. 

address contains the scaling factor applied in the PICTURE 

clause of the internal decimal item. 

decrement contains the number of nines in the PICTURE 
clause of the internal decimal item. If the number 
of nines exceeds 10, the data is treated as double- 
precision data. 

If double-precision data is involved in the move, the 
following calling sequence is used: 

TSX .CIDF2,4 

source field control word 

where the source field control word contains the same 
information as described for single-precision data. 

Subroutine .cidfi (or cidf2) converts the internal 
decimal number in the ac ( or ac-mq ) to floating point 
and leaves the result in the ac. The calling sequence 
to these subroutines is a direct entry to movpak and is 
not preceded by a tsx instruction to one of the four 
movpak entry points. 



IDID 

A move involving internal decimal data is usually 
handled by generated in-line scaling instructions. How- 
ever, if scaling of an internal decimal item is used as 
an intermediate stage of a multistage move, the scaling 
function is performed by a movpak subroutine, e.g., 
see idsd. 

IDIN 

If an internal decimal item is to be converted to another 
internal decimal item not synchronized right, the fol- 
lowing calling sequence is used: 

TXI .CIDIN,l,number 
where number is the character length of the receiving 
field, i.e., the least multiple of six bits needed to con- 
tain the desired internal decimal item and its sign. 

IDRP 

If an internal decimal item is to be moved to a report 
field for editing, the following calling sequence is used: 

TXI .CIDRP,1, number 
where number is the number of digits to be edited. 
This instruction is followed by one or more instructions 
from the report field instruction set. The instructions 
used depend on the characters that constitute the 
picture clause for the report field. The members of 
the instruction set have the following general form : 

TXI entpt,l, number 
where entpt is one of several entry points, and number 
is the number of consecutive occurrences of the char- 
acter in the picture clause. The entry point may be one 
of the following, depending on the character used: 

.CR999 if the character in the PICTURE is a 9 

.CRZZZ if the character in the PICTURE is a Z 

.CRAAA if the character in the PICTURE is an * 

.CR000 if the character in the PICTURE is a 

.CRBBB if the character in the PICTURE is a B 

Another series of instructions inserts a character into 
the report field. In the following instruction, the partic- 
ular character inserted depends on the sign of the re- 
port field: 

TXI .CRSIN,l,characterH-64*character2 
where characterl is inserted if the sign of the report 
field is plus, and character2 is inserted if the sign of the 
report field is minus. 

Note: Symbols such as "characterl" refer to the 
decimal representation of the desired bcd character. 
The bcd character is first converted to octal, and then 
to decimal before insertion. (See Example 1 which 
follows. ) 

In the following instruction, the particular character 
inserted depends on the insertion of a significant digit 
in the report field: 

TXI .CRSIG,l,eharacter3 + 64*eharaeter4 
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where character3 is inserted if a preceding significant 
digit has been inserted, and character4 is inserted if a 
preceding significant digit has not been inserted. If the 
following instruction has been executed, and the 
floating-sign character has not been inserted, the char- 
acter inserted in the report field may be character4, 
character5, or character6: 

TXI .CRFLS,1, character5 + 64*character6 
where character5 is the floating-sign character ulti- 
mately inserted in the report field if the field is plus, 
and character6 is inserted if the field is minus. If the 
first digit value in the source field is zero, a blank or 
the appropriate choice of character5 or character6 is 
inserted as a result of this instruction. The first floating- 
sign position is passed over and not counted by this 
instruction. 

The possible combination of character pairs is as 
follows: 



CHARACTER 

NUMBER 
1 

2 

3 
4 

5 
6 



CHARACTER PAIRS 

+ space space space space space 
- - C R D B 



, space 
+ space 



The following instruction is used when other floating- 
sign positions follow the position just filled: 

TXI .CRFFF,l,number 
where number is the total number of consecutive 
floating-sign positions. 

The following instruction is used when no other 
floating-sign positions follow the position just filled: 

TXI .CRFFQ,l,number 
where number is the total number of consecutive 
floating-sign positions. 

If no other floating-sign positions follow, but a 
comma precedes the next digit, the following instruc- 
tion is used: 

TXI .CRFFC,l,number 
where number is the total number of consecutive 
floating-sign positions. 

The report field string is terminated by the following 
instruction : 

TXI .CRQIT.l, value 
where value contains a zero if zero suppression is not 
desired, and contains the character length of the re- 
ceiving field if zero suppression is desired. 

The following examples show the series of instruc- 
tions needed to handle picture clauses for two report 
fields. 

Example 1: picture is $•$$, ss$, 99 is handled by the fol- 
lowing instructions: 



TXI .CRFLS,1,43 + 64*43 

character5 and character6 are $ 
TXI .CRFFF,1,2 
TXI .CRSIG,l,59 + 64*48 

character3 is a , and character4 is 

a space 
TXI .CRFFQ,1,3 
TXI .CRSIN,1,27 + 64*27 

character 1 and character2 are . 
TXI .CR999,1,2 
TXI .CRQIT,1,0 

Example 2: picture is zzz,zzz.zz+ is handled by the 

following: 

TXI .CRZZZ,1,3 

TXI .CRSIG,l,59 + 64*48 

character3 is a , and character4 is 

a space 
TXI .CRZZZ,1,3 
TXI .CRSIN,1,27 + 64*27 

character 1 and character2 are . 
TXI .CR999,1,2 
TXI .CRSIN,1, 16 + 64*32 

characterl is a + and character2 

TXI .CRQIT,1,11 

IDSD 

If an internal decimal item in the accumulator or in the 
combined accumulator and multiplier-quotient is to be 
converted to a scientific decimal item, the following 
calling sequence is used: 

TXI .CIDSD,1,0 
source field control word 
receiving field control word 

where the source field control word contains the fol- 
lowing information: 

prefix PZE if the scaling factor is positive; MZE if the 

scaling factor is negative. 

address contains the scaling factor applied in the PICTURE 

clause of the internal decimal item. 

decrement contains the number of nines in the PICTURE 
clause of the internal decimal item. If the number 
of nines exceeds 10, the data is treated as double- 
precision data. 

and the receiving field control word contains the fol- 
lowing information about the picture clause of the 
scientific decimal item: 

prefix PZE if no decimal point appears in the PICTURE 

clause; MZE if a decimal point appears in the PIC- 
TURE clause. 

address contains the scaling factor applied to the mantissa 

of the PICTURE clause. 

tag if the mantissa is negative and the exponent is 

negative; 1 if the mantissa is negative and the ex- 
ponent is positive; 2 if the mantissa is positive and 
the exponent is negative; 3 if the mantissa is posi- 
tive and the exponent is positive. 

decrement contains the total length of the receiving field in 
characters. 

IDXD 

The internal decimal item in the accumulator or in the 
combined accumulator and multiplier-quotient is con- 
verted to external decimal by one of the following three 
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calls, depending on the sign provision of the receiving 
field- 
It the receiving field has no sign provision, the fol- 
lowing calling sequence is used: 

TXI .CIDXl,l,number 
where number is the number of characters to be 
converted. 

If the receiving field always has a sign over the low- 
order bit, the following calling sequence is used: 

TXI .CIDX2,1, number 

1 —l,,-.*- 1„ 4-V./-. tmtnViar nf /-> n o t o r>t£>r e tn r»P 

converted. 

If the receiving field has a sign over the low-order 
bit when the sign is minus, the following calling se- 
quence is used: 

TXI .CIDX4,l,number 
where number is the number of characters to be 
converted. 

INAN 

An internal decimal item not synchronized right is 
converted to a synchronized internal decimal number 
(inid) before the conversion to alphanumeric is com- 
pleted (idan). 

INFP 

An internal decimal item not synchronized right is first 
synchronized right ( inid ) before the item is converted 
to floating point ( idfp ) . 

INID 

If an internal decimal item not synchronized right is 
to be converted to a synchronized internal decimal 
item, the following calling sequence is used: 

TXI .CINID,l,number 
where number is the character length of the source 
field, i.e., the least multiple of six bits needed to con- 
tain the defined internal decimal field and its sign. The 
results are left in the accumulator or in the combined 
accumulator and multiplier-quotient. The resulting 
internal decimal number is then scaled as desired 
( idid ) . 

ININ 

If a move involves internal decimal items not synchro- 
nized right, the source field is first converted to a 
normal synchronized internal decimal item (inid) for 
decimal point alignment. The resulting item is con- 
verted to the desired internal decimal item not synchro- 
nized right ( idin ) . 

INRP 

To move an internal decimal item that is not synchro- 
nized right to a report field, the source item is first 



converted to a synchronized internal decimal item 
(inid). The resulting internal decimal item is then 
moved to the report field ( idrp ) and edited as desired. 

INSD 

If an internal decimal item that is not synchronized 
right is to be converted to a scientific decimal item, the 
source item is first converted to a synchronized internal 
decimal item (inid). The resulting internal decimal 
item is then converted to scientific decimal (idsd). 

INXD 

If an internal decimal item that is not synchronized 
right is to be converted to an external decimal item, 
the source item is first converted to a synchronized 
internal decimal item (inid). The resulting internal 
decimal item is then converted to scientific decimal 

( IDXD ) . 

RPAN 

If an item in a report field is to be moved to an alpha- 
numeric field, the data in the report field is treated as 
alphanumeric data ( anan ) . 

SDAN 

If a scientific decimal item is to be converted to an 
alphanumeric item, the scientific decimal item is 
treated as an external decimal item ( xdan ) . 

5PFP 

If a single-precision scientific decimal item is to be 

converted to a floating point item, the following calling 

sequence is used: 

TXI .CSDF1,1,0 
source field control word 

where the source field control word contains the follow- 
ing information about the picture clause of the scien- 
tific decimal item: 

prefix PZE if no decimal point appears in the PICTURE 

clause; MZE if a decimal point appears in the 
PICTURE clause. 

address contains the scaling factor applied to the mantissa 

in the PICTURE clause. 

tag if the mantissa is negative and the exponent is 

negative; 1 if the mantissa is negative and the ex- 
ponent is positive; 2 if the mantissa is positive and 
the exponent is negative; 3 if the mantissa is posi- 
tive and the exponent is positive. 

decrement contains the total length of the receiving field in 
characters. 

If the item is double-precision, the following calling 

sequence is used: 

TXI .CSDF2,1,0 
source field control word 

where the source field control word contains the same 
information as described for a single-precision item. 

Subroutine .csdfi (or .csdf2) converts the free-form 
contents of the scientific decimal field to single- 
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precision floating point in the accumulator (or to 
double-precision floating point in the combined ac- 
cumulator and multiplier-quotient). 

SDID 

If a scientific decimal item is to be converted to an 
internal decimal item, the following calling sequence 
is used: 

TXI .CSDID,1,0 
source field control word 
receiving field control word 

where the source field control word contains the fol- 
lowing information: 

prefix PZE if no decimal point appears in the PICTURE 

clause; MZE if a decimal point apears in the 
PICTURE clause. 

address contains the scaling factor applied to the mantissa 

in the PICTURE clause. 

ta S if the mantissa is negative and the exponent is 

negative; 1 if the mantissa is negative and the ex- 
ponent is positive; 2 if the mantissa is positive and 
the exponent is negative; 3 if the mantissa is posi- 
tive and the exponent is positive. 

decrement contains the total length of the receiving field in 
characters. 

and the receiving field control word contains the fol- 
lowing information: 

prefix PZE if the scaling factor to be used is positive; 

MZE if the scaling factor to be used is negative. 

address contains the scaling factor applied in the PICTURE 

clause of the internal decimal item. 

decrement contains the number of nines in the PICTURE 
clause of the internal decimal item. If the number 
of nines exceeds 10, the data is treated as double- 
precision data. 

Subroutine .csdid converts the numeric contents of 
the scientific decimal field to internal decimal and 
leaves the result in the accumulator or in the combined 
accumulator and multiplier-quotient. 

SDIN 

If a scientific decimal item is to be converted to an 
internal decimal item not synchronized right, the 
source item is first converted to a normal internal deci- 
mal item (sdid). The resulting internal decimal item 
is then converted to an internal decimal item that is 
not synchronized right (idin). 

SDRP 

If a scientific decimal item is to be moved to a report 
field and edited, the source item is first converted to 
an internal decimal item (sdid). The resulting internal 
decimal item is then moved to the report field (roup) 
and edited as desired. 

SDSD 

If a scientific decimal item is to be converted to another 
scientific decimal item of a different form, the following 
calling sequence is used: 



TXI .CSDSD,1,0 
source field control word 
receiving field control word 

where the source-field and receiving-field control words 
both contain the following information: 

prefix PZE if no decimal point appears in the PICTURE 

clause; MZE if a decimal point appears in the 
PICTURE clause. 

address contains the scaling factor applied to the mantissa 

in the PICTURE clause. 

tag if the mantissa is negative and the exponent is 

negative; 1 if the mantissa is negative and the ex- 
ponent is positive; 2 if the mantissa is positive and 
the exponent is negative; 3 if the mantissa is posi- 
tive and the exponent is positive. 

decrement contains the total length of the receiving field in 
characters. 

SDXD 

If a scientific decimal item is to be converted to an 
external decimal item, the source item is first converted 
to internal decimal (sdid). The resulting internal deci- 
mal item is then converted to external (idxd). 

SPAA, SPAN, SPRP, SPSD, SPXD 

If spaces or blanks are to be moved to an alphabetic, 
alphanumeric, report, scientific decimal, or external 
decimal field, the following calling sequence is used: 

TXI .CSPAN,l,number 
where number is the number of spaces to be inserted. 

XDAN 

If an external decimal item is to be moved to an alpha- 
numeric field, the data is treated as alphanumeric data 
and the move is carried out accordingly ( anan ) . 

XDFP 

If an external decimal item is to be converted to floating 
point, the source item is first converted to internal deci- 
mal (xdid). The resulting internal decimal item is then 
converted to floating point ( idfp ) . 

XDID 

If an external decimal item is to be converted to an 
internal decimal item, the source item is first converted 
to internal decimal without scaling and the result is 
left in the accumulator or in the combined accumulator 
and multiplier-quotient. The sign of the source field is 
assumed to be over the low-order digit. The absence of 
a sign is treated as a plus. 

Leading spaces in the source field are treated as 
zeros. The following calling sequence is used to call 
the subroutine to perform the conversion: 

TXI .CXDID,l,number 
where number is the number of characters needed to 
convert the data to internal decimal. 
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If scaling is needed, the internal decimal result is 
converted to another internal decimal item with the 
desired scaling (idid). 

XDIN 

If an external decimal item is to be converted to in- 
ternal decimal not right synchronized, the source item 
is first converted to internal decimal (xdid) right 
synchronized. The resulting internal decimal item is 
then scaled if necessary (idid), and converted to an 
internal decimal item not synchronized (idix). 

XDRP 

If an external decimal item is to be moved to a report 
field and edited, the following calling sequence is used: 

TXI .CXDRP,1,0 
followed by one or more instructions from the external 
decimal txi instruction set. The particular instructions 
used represent a means of constructing the proper 
string of digits for the receiving field. The instructions 
in the external decimal set are explained in the section 
"xdxd." 

After the series of instructions from the external deci- 
mal set, the following instruction is used: 

TXI .CXDRQ,l,number 
where number is the number of digits in the string pre- 
pared for the receiving field by the external decimal 
subroutine set. 

Once the source item has been prepared for the 
receiving field, another series of instructions irom the 
report field instruction set is used. These instructions 
are explained in the section describing the move of an 
internal decimal item to a report field ( idrp ) . 

The entire series of instructions for the move from 
external decimal to a report field is concluded by the 
following instruction: 

TXI .CRQIT,l,value 
where value equals if zero suppression is not wanted. 
If zero suppression is desired, value is the number of 
characters in the picture clause for the report field. 

XD5D 

If an external decimal item is to be converted to a scien- 
tific decimal item, the source item is first converted to 
internal decimal ( xdid ) . The resulting internal decimal 
item is then converted to scientific decimal ( idsd ) . 

XDXD 

If only external decimal items are involved in a move 
or conversion operation, the following calling sequence 
is used: 

TXI .CXDXD,l,sign 
where sign is if the receiving field has no sign pro- 
vision; 1 if the receiving field has a sign over the low- 



order digit when the sign of the field is minus; and 2 if 
the receiving field always has a sign over the low-order 
digit. 

This instruction is followed by one or more instruc- 
tions from the external decimal instruction set to con- 
struct the proper string of digits for the receiving field. 
The instructions used depend on the operation to be 
performed in preparing the string. The instructions in 
this set have the following form: 

TXI entpt,l, number 
where entpt is one of several entry points, and number 
is the number of digits involved in the desired opera- 
tion. The entry point may be one of the following, de- 
pending on the operation to be performed: 

.CXMOV if the digits are to be moved 

.CXNZT if the digits are to be tested for nonzero 

.CXBYP if the digits are to be bypassed 

.CXINZ if the digits are to be inserted 

.CXRND if a rounding operation is to be performed at the 

current position (number for this entry point is 

zero) 

If a nonzero condition is encountered while using 
subroutine .cxnzt, location .coflo is set to nonzero. 
Three alternate entry points (.cxmvs, .cxnzs, and 
.cxbys ) corresponding to entry points .cxmov, .cxnzt, 
and .cxbyp are used if a sign appears over the last 
digit involved in the operation. 

The following instruction terminates the instruction 
set for this move: 

TXI .CXDXQ,l,number 
where number is the number of digits in the string pre- 
pared for the receiving field. The following examples 
show coding necessary to handle two cobol source 
program statements. 

Examvle 1: The statement compute b rounded = a, 
on size error . . . ( where a's picture is S999V999 and b's 
picture is S9V9 ) results in the following move-call cod- 
ing: 

TXI .CXDXD 5 1,2 

TXI .CXNZT,1,2 

TXI .CXMOV,l,2 

TXI .CXRND,1,0 

TXI .CXBYS,1,2 

TXI .CXDXQ,1,2 

Example 2: The statement move a to b ( where as 
picture is S9V99 and b's picture is V9999 ) results in the 
following move call-coding: 



TXI 
TXI 
TXI 
TXI 
TXI 



.CXDXD,1,0 
.CXBYP, 1,1 
.CXMVS,1,2 
.CXINZ,1,2 
.CXDXQ,1,4 



ZEAN 



If zeros are to be moved to an alphanumeric field, the 
following calling sequence is used: 

TXI .CZE AN, 1, number 
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where number is the number of zeros to insert in the 
field. 

ZEFP, ZEID 

If zeros are to be stored in a floating point or internal 
decimal item, movpak subroutines are not used. The 
value zero is stored by one or more generated in-line 
instructions. 

ZERP 

If zeros are to be moved to a report field, the required 
number of zero digits is provided by generated in-line 
instructions. These zeros are placed in one or more 
temporary storage words. The move is then treated as 
a move from external decimal to a report field (xdrp). 

ZESD 

If zeros are to be inserted in a scientific item, the ac- 
cumulator is cleared to zero by the following generated 
in-line instruction: 

CLA location 
where location contains all zeros. 

The move is then treated as a move from floating 
point to scientific decimal (fpsd). 

ZEXD 

If zeros are to be inserted in an external decimal item, 
the move is treated as a move of zeros to an alphameric 
field ( zean ) . 

COBOL Input/Output Subroutines 

A group of cobol input/output subroutines are pro- 
vided to service cobol programs. Some of these sub- 
routines use communication location .ciohs to keep a 
history of input/output operations. Location .ciohs is 
of the form: 

PZE 0,0,** 
where the decrement contains the source language 
card number of the most recent input/output operation. 
This location is set by every open, close, read, and 
write statement in the source program. 

All cobol input/output subroutines except .ciohs are 
described in the following text in alphabetical order 
according to the symbolic name of the subroutine. In 
the following descriptions, the notation cp + nnn is used 
to refer to a location in the constant pool. The informa- 
tion contained in this location is explained each time 
the notation is used. 

.ACEPT 

The .acept subroutine accepts data from an on-linp 
peripheral device. The calling sequence for this sub- 
routine is: 

TSX .ACEPT,4 

PZE WS + nnn„device 



where ws + nnn is the location of the first word of a 12- 
word bcd input area in working storage and device is 
an actual bit configuration that may be either of the 
following: 

Bit 16 = 1 if the peripheral device is the system input unit. 
Bit 17 = 1 if the peripheral device is the card reader. 

.CBLER 

Subroutine .cbler is called if a base locator that has 
not been set is referred to. An error message is written 
on the system output unit, a core storage dump is taken, 
and execution of the object program is terminated. The 
calling sequence for this subroutine varies. 

.CCDTY 

Subroutine .ccdty determines if card equipment is to 
be used for an input/output operation. The calling 
sequence for this subroutine is: 

TSX .CCDTY,4 
PZE file-name 
( returnl ) 
( return2 ) 

where file-name is the name of the file used in the re- 
quired operation, returnl is used if card equipment is 
to be used, and return2 is used if card equipment is 
not to be used. 

.CCLOS 

Subroutine .cclos closes input/output files. The calling 
sequence for this subroutine is: 

TSX .CCLOS,4 
rop file-name„opt 

where file-name is the name of the file to be closed, rop 
is the rewind option and may be one of the following: 

PZE Rewind and unload 

PTW Rewind 

MZE No rewind 

MON No rewind, no end-of-file mark 

and opt describes the type of file and indicates the 
close reel option as follows: 

opt = if the file-name does not refer to an optional file and 
the CLOSE REEL option is not wanted. 
= 1 if the file-name refers to an optional file. 
= 2 if the CLOSE REEL option is desired. 
= 3 if the file-name refers to an optional file and the 
CLOSE REEL option is desired. 

.CD1SP 

Subroutine .cdisp is used to display any number of data 
items on either the printer or the system output unit. 
The calling sequence for this subroutine is : 

\ Stores over CALL 
CAL SP + nnn ^ parameters where 

SLW GNxxx+m + 2 ( the starting byte 

J does not = 0. 
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GNxxx 



CALL 


.CDISP,4 


TXI 


* + 2 + n„n 


PZE 


device„iinkage director 


PZE 


location i„bytei 


PZE 


locatiori2„byte2 



PZE locationm,,bytem 



PZE location n „byten 

TRA *+l+n 

PZE lengtlii„forrnati 

PZE length2„format2 



PZE lengthn„formatn 

where: 

n is the number of items to be displayed; n can vary 
from m to 1. 

device is one of the following: 

if the items are to be displayed on the printer 

1 if the items are to be displayed on the system 
output unit 

location! is the first- word address of the items or area 
to be displayed. 

byte; is the byte displacement for the first item of 
the data to be displayed. 

length) is either the length of the item in characters 
or the address or the location containing tue iengtn, 
depending on the format code. 

format; is one of the following: 

for alphabetic or alphameric items where lengthj 
is the length. 

1 for external decimal, scientific decimal, or report 
items where length is the length. 

2 for internal decimal items where lengthi is a 
maximum of 18 characters; if more than 18 char- 
acters are specified, the item is truncated to 18 
characters. 

3 for floating point items where lengthi is the 
length. 

4 for bcd items where lengths is the address of a 
location containing the length of the item in 
characters. 

5 for bcd items where lengthi is the address of a 
location containing the length of the item in 
words. 

The first-word address and byte displacement may 
have to be determined and placed in the calling 
sequence at execution time via the cla and slw instruc- 
tions. 



.CDPLY 

Subroutine ,cdply is used to display a 12-word bcd 
image. The calling sequence for this subroutine is: 

TSX .CDPLY,4 
PZE image„device 
(Return) 

where image is the address of the area to be displayed, 

and device is an actual bit configuration that may be 

one of the following: 

Bit 15 = 1 if the area is to be displayed on the printer. 

Bit 14=1 if the area is to be displayed on the system output 

unit. 
Bit 13 = 1 if the area is to be displayed on the card punch. 

This option is not currently implemented. 

.CEOBP 

Subroutine .ceobp is associated with an iocs .read or 
.write calling sequence. Control is transferred to sub- 
routine .ceobp when the iocs end-of -buffer error condi- 
tion is encountered. This subroutine writes an error 
message and causes execution of the object program 
to be terminated. 

.CERRP 

Subroutine .cerrp is associated with an iocs .read 
calling sequence. Control is normally transferred to 
subroutine .cerrp when the iocs error condition is en- 
countered during a .read calling sequence. This sub- 
routine writes an error message and causes execution of 
the object program to be terminated. 

.CEXNG 

Subroutine .cexng is an error routine, called only by 
.CAROi, .caro2, .CAR13, or cari4 when the factors in an 
exponentiation operation are out of range. This sub- 
routine prints an off-line error message indicating tue 
location of the error within the program. The calling 
sequence for this subroutine is: 

TSX .CEXNG,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
number of the source language card that specified the 
original computation. 

.CEXPR 

Subroutine .cexpr is called only by .caroi, .caro2, 
.cari3, or .cari4 to determine if the factors in an ex- 
ponentiation operation are out of range. If they are, the 
error routine .cxng is used; if they are not out of range, 
the execution of the object program continues. The 
calling sequence for this subroutine is: 

TSX .CEXPR,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
number of the source language card that specified the 
original computation. 
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XKEYS 

Subroutine .ckeys places the setting of the entry keys 
in the multiplier-quotient register. The calling sequence 
for this subroutine is: 

TSX .CKEYS,4 
( Return) 

XOPEN 

Subroutine .copen opens input/output files. The calling 
sequence for this subroutine is: 

TSX .COPEN,4 

rop filename, , opt 

where filename is the name of the file to be opened, 
rop is the rewind option and may be one of the follow- 
ing: 

PZE Rewind 

MZE No rewind 

MON No rewind, no label action 

and opt equals 1 if the file name refers to an optional 
file. 

Additional COBOL Subroutines 

cobol subroutines are also provided to perform addi- 
tional conversion operations, mathematical computa- 
tions, and alphabetic comparisons. These subroutines 
use two locations for temporary storage of data used 
by the subroutines. Location .carsi is used if the data 
is single-precision, and locations .carsi and .cars2 are 
used if the data is double-precision. 

These subroutines are listed in alphabetical order ac- 
cording to the symbolic name of the subroutine. In the 
following descriptions, the notation cp + nnn is used to 
refer to a location in the constant pool. The information 
contained in this location is explained each time the 
notation is used. 

.CAR01 

Subroutine .caroi raises the double-precision floating- 
point number in the combined accumulator and multi- 
plier-quotient to the single-precision power in .carsi. 
The double-precision floating-point result is in the com- 
bined accumulator and multiplier-quotient. The calling 
sequence for this subroutine is: 

TSX .CAROI 
PZE CP + nnn 

where cp + nnn is a location in the constant pool. This 
location contains the source language card number at 
which the original computation was specified. This con- 
stant is used by error routine .cexng only if the factors 
in the exponentiation are out of range. 

.CAR02 

Subroutine .caro2 raises the double-precision floating- 
point number in the combined accumulator and multi- 
plier-quotient to the double-precision power in .carsi 



and .cars2. The double-precision floating-point result 
is in the combined accumulator and multiplier-quotient. 
The calling sequence for this subroutine is: 



TSX .CAR02,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
number of the source language card that specified the 
original computation. This information is used only in 
case of error. 

.CAR03 

Subroutine .caro3 adjusts the sign of a double-precision 
fixed-point number located in the combined accumula- 
tor and multiplier-quotient. The result is left in the 
combined accumulator and multiplier-quotient. The 
calling sequence for this subroutine is: 

TSX .CAR03,4 
XAR04 

Subroutine .caro4 scales up the single-precision num- 
ber in the accumulator by lxlO 10 and then scales up 
the result by a constant located in the constant pool. 
The calling sequence for this subroutine is: 

TSX .CAR04,4 
tZt, cP + nnn 

where cp + nnn specifies the location containing the 
second scaling factor. 

.CAR05 

Subroutine .caroo scales up the number in the multi- 
plier-quotient by lxlO 10 and then scales up the result 
by a constant located in the constant pool. The calling 
sequence for this subroutine is: 

TSX .CAR05.4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
second scaling factor. 

.CAR06 

Subroutine .caro6 scales up the double-precision num- 
ber in the combined accumulator and multiplier- 
quotient by a constant located in the constant pool. 
Upon entry to this subroutine, the high-order part of 
the number is in the accumulator and the low-order 
part of the numbers is in the multiplier-quotient. The 
calling sequence for this subroutine is : 

TSX .CAR06,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
scaling factor. 

.CAR07 

Subroutine .carot scales up the double-precision num- 
ber in the combined accumulator and multiplier- 
quotient by a constant in the constant pool. Upon entry 
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to this subroutine, the high-order part of the number is 
in the multi^lier-nuotient and the low-order part of the 
number is in the accumulator. The calling sequence 
for this subroutine is: 

TSX .CAR07,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
scaling factor. 

.CAR08 

Subroutine .caros scales down the double-precision 
number in the combined accumulator and multiplier- 
quotient by a constant. The result is in the combined 
accumulator and multiplier-quotient. The calling se- 
quence for this subroutine is : 

TSX .CAR08,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
scalinff factor. 

.CAR09 

Subroutine .caro9 scales down the double-precision 
number in the combined accumulator and multiplier- 
quotient by lxlO 10 and then scales down the result by 
a constant. The result is in the multiplier-quotient. The 
calling sequence for this subroutine is: 

TSX .CAR09,4 
PZE CP + nnn 

where cp+nnn specifies the location containing the 
scaling factor. 

.CAR10 

Subroutine .cario divides the double-precision fixed- 
point number in locations .carsi and .cars2 by the 
double-precision number in the combined accumulator 
and multiplier-quotient. The result is in the combined 
accumulator and multiplier-quotient. The calling se- 
quence for this subroutine is : 

TSX .CAR10,4 

.CAR? I 

Subroutine .carii multiplies the double-precision num- 
ber in the combined accumulator and multiplier- 
quotient by the double-precision number in locations 
.carsi and .cars2. This subroutine also scales down the 
result by a constant and leaves the final result in the 
combined accumulator and multiplier-quotient. The 
calling sequence for this subroutine is: 

TSX .CAR11,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the scal- 
ing factor used after the multiplication. 



.CAR 1 2 

Subroutine ,cari2 multiplies the double-precision num- 
ber in the combined accumulator and multiplier- 
quotient by the double-precision number in locations 
.carsi and .cars2. The result is scaled down by lxlO 10 , 
and then by a constant. The final result is in the com- 
bined accumulator and multiplier-quotient. The calling 
sequence for this subroutine is: 

TSX ,CAR12,4 
PZE CP + nnn 
...T — . :C — 4-U~ 1~~«4-;,^ ^^v,4-r.;^;^« «-!-.,-. 
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scaling factor. 

.CAR 13 

Subroutine .cari3 is a floating-point exponential rou- 
tine. The single-precision floating-point number in the 
accumulator is raised to the single-precision floating- 
point power in location .carsi. The base number in the 
accumulator may be a positive real number or a nega- 
tive integer. The exponent in location .carsi may have 
any value. The result is a single-precision floating-point 
number in the accumulator. However, the result is 
limited to an accuracy of seven significant digits. If an 
accuracy of eight or more significant digits is desired, 
the double-precision exponentiation subroutine .cari4 
must be used. Subroutine .CAR14 is called when a pic- 
ture of nine or more decimal digits is specified for 
either the base number or the exponent. Subroutine 
.CAR13 calls subroutine .cexpr to determine if the result 
exceeds seven significant digits, and if it does, calls sub- 
routine .cexng to indicate the error. The calling se- 
quence for subroutine .cari3 is: 

TSX .CAR13,4 
PZE CP + nnn 

where cp + nnn specifies the location containing the 
number of the source language card that specified the 
exponential operation. This information is used in case 
of an error. 

.CARI4 

Subroutine .cari4 is an exponential routine that uses 
either single-precision numbers or double-precision 
floating-point numbers as the base and exponent. The 
number located in the accumulator or combined ac- 
cumulator and multiplier-quotient is raised to the 
power in location .carsi (or location .carsi and .cars2). 
This subroutine is called whenever either the base or 
the exponent is a double-precision number. The result 
is a double-precision number in the combined accumu- 
lator and multiplier-quotient. Subroutine .CAR14 calls 
subroutine .cexpr, and in case of an error, calls sub- 
routine .cexng. The calling sequence for subroutine 
.CAR14 is: 

TSX .CAR14,4 
PZE CP + nnn 
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where cp + nnn specifies the location containing the 
number of the source language card which specified - 
the exponential operation. This information is used in 
case of an error. 

.CAR15 

Subroutine .cams converts the single-precision number 
in the accumulator to a double-precision number in the 
combined accumulator and multiplier-quotient. The 
calling sequence for this subroutine is: 

TSX .CAR15,4 

XBCDH 

Subroutine .cbcdh converts a 12-word bcd image to a 
card image. The calling sequence for the subroutine is: 

TSX .CBCDH,4 

PZE BL + nnn, ,TS + nnn 

where TS + nnn is the location of the first word of a 12- 
word temporary storage area containing the bcd image 
and BL+nnn is the base locator for the storage area that 
will contain the card image. 

.CBDCV 

Subroutine .cbdcv converts the bcd control word that 
precedes each variable-length record to binary form. 
This control word contains the length of the record in 
words. Upon entering this subroutine, the control word 
is in the multiplier-quotient. After conversion, the 
record length is in binary form in the decrement of the 
accumulator. The calling sequence for this subroutine 



is: 



XBNCV 



TSX .CBDCV,4 

(Return) 



Subroutine .cbncv converts the length of a variable- 
length record from binary to bcd form. Upon entering 
this subroutine, the record length in number of words 
is in the multiplier-quotient in binary form. The length 
is converted to bcd form and placed in the first five 
characters of a control word, which is added to the 
beginning of the variable-length record. The sixth char- 
acter of the control word is zero. After conversion, the 
control word is in the logical accumulator. The calling 
sequence for this subroutine is: 

TSX .CBNCV,4 
( Return ) 

.CCOMP 

Subroutine .ccomp performs an alphabetic comparison 
of two fields. The calling sequence for this subroutine 
is: 

TSX .CCOMP,4 
op .CCTAB„6 
PZE loci,ti, locator 



PZE lengthi„6*bytei 

PZE loc'2,t2,locator2 

PZE length 2 „6*byte2 

( high return from comparison ) 
( equal return from comparison ) 
( low return from comparison ) 

where op is cvr or nop, depending on the need to adjust 
the collating sequence before the comparison. 

loci is the displacement from the base, if any. If there 
is no base, locj is the location of the field. 

locator! is the location of the base locator. If there 
is no base locator, locator is zero. 

tj is nonzero if the base locator is complex. If there is 
no base locator, ti is zero. 

lengths is the length of the field in characters. 

bytej is the nominal byte position. 

.CCTAB 

.CCTAB is a conversion table used in converting from 
the 7090 scientific collating sequence to the collate- 
commercial collating sequence used in cobol. This 
table is used by subroutine .ccomp if it is necessary to 
adjust the collating sequence before performing an 
alphabetic comparison of two fields. 

CGOGO 

Subroutine .cgogo provides access to Fortran mathe- 
matical subroutines from a cobol source program. It is 
called by one of 32 access subroutines, depending on 
which Fortran subroutine is desired. There is one 
access subroutine for each Fortran subroutine as shown 
in Figure 54. These 32 access subroutines are called by 
a cobol source language statement of the form: 

CALL 'COBOL-entry-point' USING R X Y. 
where COBOL-entry-point is the entry point to one of the 
32 access subroutines and R, X, and Y are the param- 
eters of an equation of the form R = f(X, Y). (If the 
equation is of the form R = f(X), the third parameter 
is not needed. ) 

The access subroutines load the accumulator with an 
indicator word before transferring control to subrou- 
tine .cgogo. The actual entry to and return from the 
Fortran subroutine is performed from subroutine 
.cgogo. Return from .cgogo is to the original program, 
not the access subroutine. These access subroutines are 
in the following form: 

xxxxxx CLA * + 2 

TRA .CGOGO 

opcode yyyyyy 

where: 

xxxxxx is the entry point to the access subroutine. 

opcode is tra if single-precision parameters are ex- 
pected as output from the Fortran subroutine, or nop 
if double-precision parameters are expected: 

yyyyyy is the desired Fortran entry point. 
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FORTRAN 
Entry Point 
.XP1. 
.XP2. 
.XP3. 
.DXP1. 
.DXP2. 
.CXP1, 
EXP 
DEXP 
CEXP 
ALOG 
DLOG 
CLOG 
ALOG 10 
DLOG 10 
ATAN 
DATAN 
ATAN2 
DATAN2 
SIN 
DSIN 
CSIN 
COS 
DCOS 
CCOS 
TANH 
SORT 
DSQRT 
CSQRT 
DMOD 
.CABS. 
.CFMP. 
.CFDP. 



COBOL 
Entry Point 
.CXP1 
.CXP2 
.CXP3 
.CDXP1 
.CDXP2 
.CCXP1 
.CEXP 
.CDEXP 
.CCEXP 
.CALOG 
.CDLOG 
.CCLOG 
.CAL10 
.CDL10 
.CATAN 
.CDATN 
.CATN2 
.CDAT2 
.CSIN 
.CDSIN 
.CCSIN 
.CCOS 
.CDCOS 
.CCCOS 
.CTANH 
.CSQRT 
.CDSQR 
.CCSQR 
.CDMOD 
.CCABS 
.CCFMP 
.CCFDP 



.CHBCD 

Subroutine .chbcd converts a card image to a 12-word 
bcd image. The calling sequence for this subroutine is: 

TSX .CHBCD,4 

PZE .BL + nnn„TS + nnn 

where BL+nnn specifies the area containing the card 
image and TS + nnn is the first address of a 12- word 
temporary storage area that will contain the bcd image. 



Correspondence Between the Entry Point to the 
FORTRAN Subroutine and the Entry Point to the 
COBOL Access Subroutine 
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Librarian 



The Librarian is a section of the Loader used to main- 
tain the Subroutine Library. By using the Librarian, 
subroutines can be replaced in, added to, and deleted 
from the Library. Any subroutines added to the Library 
must first be assembled by the Macro Assembly Pro- 
gram. 



Subroutine Library Maintenance 

The Subroutine Library consists of the following two 
files of information: 

1. The control information file, consisting of the 
subroutine section-name table; the subroutine depend- 
ence table, and the Loader control cards, control dic- 
tionaries, and file dictionaries, if they exist. 

2. The relocatable binary text file, consisting of the 
text portions of those library subroutines that have text. 

Tue Library maintenance operation is essentially a 
four-phase process. The name table and the depend- 
ence table are skipped, and not used by the Librarian. 
Librarian control cards and subroutine decks are ob- 
tained from the input file. Appropriate positioning, re- 
placements, insertions, or deletions are made in the 
control information file and the new control information 
file is formed and written on a work file. 

The relocatable binary text portions of the subrou- 
tine decks obtained from the input file are written on a 
second work file. The operation and subroutine name 
from each Librarian control card are preserved in the 
Librarian action table to be used in processing the re- 
locatable binary text file. At the completion of phase 1, 
the complete control information file has been formed. 

In phase 2, the relocatable binary text portions of the 
subroutines obtained from the input file are merged 
with the existing text file, and the new relocatable 
binary text file is written behind the new control in- 
formation file. 

In phase 3, the combined control dictionaries of the 
library subroutines are used to generate the new sub- 
routine section name table and the subroutine section 
dependence table. If the programmer so specifies on 
the sedit card (see below), a listing is prepared show- 
ing the subroutine name, the origin, if fixed, the length, 
and the starting record number of each subroutine. A 
list showing all real control sections and their depend- 
encies is also produced. 

Phase 4 consists of writing the subroutine section 
name table and subroutine section dependence table 



on the system utility unit (sysut4), followed by the 
control information and text files. 

Subroutine Library maintenance is now complete, 
and the Librarian returns control to the Loader. A 
system edit is now necessary to replace the existing 
library files by the two new Library files generated by 
the Librarian on the system utility unit ( sysut4 ) . 

Note: Subroutine Library maintenance normally fol- 
lows an update of the Library symbolic input tape ( see 
IBM 7090/7094 IBSYS Operating System: Symbolic 
Update Program, Form C28-6386). It can also be 
accomplished without symbolic update by using the 
alter feature of ibjob ( see "Altering an Input Deck" ) . 



Librarian Control Cards 

The following control cards are necessary for the use of 

fn^ T inrorion» 

$EDIT Card 

The sedit card must follow the Processor control card 
( sibjob card ) . The sedit card causes the Librarian to be 
called by the Load Supervisor. 
The format of this control card is : 

1 16 

SEDIT [LOGIC] 

If the logic option is specified, the Librarian pro- 
vides information showing the cross-referencing of sub- 
routines in the Library. 

$REPLACE Card 

The sreplace card causes a subroutine in the Subrou- 
tine Library to be replaced. 

The format of this control card is : 

1 16 

SREPLACE srname [, ORG = nnnnn] 

The current Library is copied up to, but not including, 
the subroutine name symbolized by srname. The 
named subroutine is then skipped in the current Library 
and the subroutine deck following the sreplace card 
is inserted in its place in the output Library files. If the 
subroutine deck is in map source language and must be 
assembled, it must be headed by a sibmap card. If it 
has already been assembled and is in relocatable binary 
form, the deck must be headed by a sibldr card. 

The optional field org = nnnnn is used to assign an 
absolute origin to the subroutine that is being inserted 
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or to change its assembled absolute origin. The five- $AFTER Card 
digit field nnnnn is the absolute oricin in octal. 



$ASSIGN Card 

The sassign card causes a subroutine to be assigned an 
absolute origin before it is placed in the Subroutine 
Library. 

The format of this control card is: 

1 16 

SASSIGN srname, ORG = nnnnn 

The Librarian copies the current Library up to, but 
not including, the subroutine name symbolized by 
srname. The named subroutine is then assigned the ab- 
solute origin specified by the octal number nnnnn and 
the subroutine is placed in the output library files. 

Both the subroutine named and the origin to be as- 
signed are mandatory on this control card. 

$iNSERT Card 

The sinsert card causes the Librarian to write a sub- 
routine deck onto the Library file. The card must 
precede the subroutine deck. The deck is written onto 
the file, starting with the current position of the file. 

If the subroutine deck is in map source language 
and must be assembled, it must be headed by a sibmap 
card. If it has already been assembled and is in re- 
locatable binary form, the deck must be headed by a 
sibldr card. 

The format of this control card is: 

1 16 

$INSERT [srname] [, ORG = nnnnnl 

The field srname is optional on this control card and 
will not be used by the Librarian. The optional field 
org = nnnnn is used to assign an absolute origin to the 
subroutine being inserted. 

It should be noted that positioning is not performed 
with the sinsert card; the insertion is made at the 
current position of the output Library file. 
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The format of this control card is : 

1 1(5 

$ AFTER srname 

The safter card causes the Librarian to copy the 
Library from its current position through the subrou- 
tine name symbolized by srname. The subroutine name 
is mandatory on this control card. 

The $after card is used in conjunction with the 
sinsert card to position the tile before inserting. 

$DELETE Card 

The sdelete card causes subroutines to be removed 
from the Subroutine Library. 

The format of this control card is : 

1 16 

SDELETE srname 

The sdelete card causes the Librarian to copy the 
Library from its current position up to, but not includ- 
ing, the subroutine symbolized by srname. The named 
subroutine is then skipped on the current Library. The 
subroutine name is mandatory on this control card. 

Restrictions Using Disk 

If the Subroutine Library is to reside on disk storage, 
the system utility unit (sYstm) must be attached to 
the disk to obtain the proper block size. If sysut4 is 
not attached to disk, sysut.3 may not be attached to disk. 

Restrictions Using Drum 

The block size of the Subroutine Library is determined 
by the Loader assembly parameter drum. If drum = o, 
the block size is 464 words; if drum = i, the block 
size is 524 words. As released, drum = o. The entire 
Loader must be reassembled to set drum = i . ( See 
"System Library Preparation and Maintenance" in the 
publication IBM 7090/7094 IBSYS Operating System: 
System Monitor (IBSYS), Form C28-6248. ) 
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PART 3: IBJOB PROCESSOR ERROR MESSAGES 



The following section lists the messages generated by 
the ibjob Processor. The messages are arranged by 
component as follows: Monitor, fortban iv Compiler, 
cobol Compiler, Assembler, Load-Time Debugging 
Processor, Loader, and Subroutine Library. 

To find the explanation for a message, the pro- 
grammer should consider the sequence of Processor 



operations as indicated by the printed assembly listing. 
For example, a message printed on a listing after a 
sibftc card and before the next component control card 
has been generated by the Fortran iv Compiler. A 
message printed after a sibldr card has been generated 
by the Loader. 
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IBJOB Monitor Error Messages 



The following section lists, in alphabetical order, the 
messages generated by the ibjob Monitor. The symbol 
«******" i n di ca tes a location in the error message 
where the Compiler inserts a variable word. Where 
such a word is the first in the message, the message is 
listed alphabetically by the next nonvariable word. 

ABSMOD ASSEMBLIES CANNOT BE LOADED. 

This message occurs when the ABSMOD option is en- 
countered on a SIBMAP card, and loading is requested. 
A systems error is indicated. 

ACTION LABEL INCORRECT. 

This message occurs if an argument to the Action routine, 
sent by some part of the system to cause positioning or 
reading of the system unit, does not match any action 
table entries. A systems error is indicated. 

ALTER FIELD ERROR, CARD AND INSERTIONS 
IGNORED. 

This message occurs when a comma or blank is encoun- 
tered in column 16 of an *ALTER control card or when 
a field is written as follows: (A* ALTER B, ,) or 
(A*ALTERB,). 

ALTER FIELD ERROR, COMMA TREATED AS BLANK. 

This message occurs when a comma is encountered in 
columns 1-6 of an *ALTER control card or when a field 
is written as follows: (A* ALTER B ,C,). In the latter 
case, the last comma is treated as a blank. 

ASSEMBLY DELETED. 

This message occurs if an error in compilation has 
occurred such that assembly cannot be attempted. 

BINARY RECORD(S) ENCOUNTERED WHILE SEARCH- 
ING FOR CARDS. 

This message occurs when binary records are encoun- 
tered by the IBJOB Monitor outside the limits of an 
object deck. 

****** CARD WITH CORRECT DECK NAME NOT FOUND. 

This message occurs when alternate input is requested 
and the deck requested cannot be found. 

DUMP TABLE HAS OVERFLOWED. 

This message occurs if more than 29 table words have 
been generated because of $DUMP cards. Table words 
are generated as follows: one word for each $DUMP 
card and an additional word for each set of dump limits 
on the card. 

EOB OR EOT CONDITION. DECK CANNOT BE PROC- 
ESSED. 

This message occurs when an indication of end of buffer 
or end of tape occurs while transferring Alter cards to 
the system utility unit ( SYSUT2 ) . 

EOF OR REDUNDANCY IN ALTER FILE. 

This message occurs when an end of file or redundancy 
is encountered by the Alter routine while trying to read 
Alter cards from the system input unit or the system 
utility unit (SYSUT2). 



EOT ON INTERMEDIATE UNIT OR EOB EXIT. ERROR 

CONDITION. 

This message occurs if the system input/output editor, 
while trying to write on an input/output unit, receives 
a signal from IOCS that an end-of-buffer condition exists. 
If the unit is 1301 Disk Storage, the condition is caused 
by exceeding the cylinder limits specified for the system 
function. 

ERROR IN ALTER DECK. 

This message occurs when a deck has been altered and 
an error detected (unused Alter cards, an end of file or 
redundancy while reading Alter cards, or a scan error 
in an Alter card ) . 

ERROR READING OBJECT DECK. 

This message occurs when a redundancy on the system 
input unit occurs while transferring an object deck to 
the load file. 

****** HAS NO UNIT ASSIGNED. CANNOT PROCEED. 

This message occurs if the system output unit or the sys- 
tem input unit has no unit assigned when the IBJOB 
Processor gains control. 

****** HAS NO UNIT ASSIGNED. RESTRICTED USAGE 

OF IBJOB IS POSSIBLE. 

This message occurs if the system peripheral punch or 
one of the system utility units SYSUT1, SYSUT2, 
SYSUT3, or SYSUT4 has no unit assigned when the 
IBJOB Processor gains control. 

IBJOB SYSTEM SPLIT BETWEEN TWO CHANNELS IS 

ILLEGAL PROCEED TO NEXT JOB. 

This message occurs when the IBJOB Processor is split 
into two units, and they are mounted on two different 
channels. 

IBJOB VERSION ***** HAS CONTROL. 

This message occurs each time the IBJOB Processor 
gains control from the System Monitor. 

ILLEGAL BCD DATE IN BASIC MONITOR DATE CELL. 

ENTER CURRENT DATE IN KEYS (MMDDYY) AND HIT 

START. 

This message occurs in IBJOB initialization if location 
SYSDAT in the System Monitor does not contain a valid 
date. The operator should enter the current date, in 
BCD, into the keys and press START. 

INCORRECT DECK SET-UP 

The IBJOB Monitor has encountered a component con- 
trol card or an unrecognized card with a $ in column 1 
either ( 1 ) without having processed a $IBJOB card for 
the current Processor application or (2) while still in 
control after the completion of a Processor application. 
This message will not occur when the IBJOB Monitor 
encounters unrecognized control cards after a $IBJOB 
card for the current Processor application has been 
processed. 

INCORRECT DECK SET-UP, EOF ENCOUNTERED BE- 
FORE *ENDAL. 

This message occurs when Alter cards on the system 
input unit are being transferred to SYSUT2, and an end 
of file is encountered before an *ENDAL card. 
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MACHINE OR SYSTEM FAILURE HAS OCCURRED. 
RETRY IS IMPOSSIBLE. THIS JOB WILL BE CONTINUED. 

This message occurs when ( 1 ) machine or system failure 
is detected and ( 2 ) the system input unit is a card reader 
or an end-of-tape was encountered during the job. 

MACHINE OR SYSTEM FAILURE HAS OCCURRED. TO 
RETRY THIS P/A, PRESS START. TO CONTINUE THIS 
P/A, PRESS START WITH KEY "S" DOWN. TO DELETE 
THIS P/A, PRESS START WITH KEY "1" DOWN. 
Self-explanatory. 

NO PROCESSING THIS P/A. 

This message occurs when a Processor application con- 
sists of a $IBLDR card with the LIBE option, or con- 
tains no decks at all. 

ON-LINE PRINTER AND PUNCH MAY NOT BE AT- 
TACHED AS SYSOU1 AND SYSPP1. CANNOT PROCEED. 
This message occurs if either the system output unit or 
the system peripheral punch has been assigned to on-line 
equipment. 

ONLY SYSIN1, SYSOU1, SYSPP1 WILL BE REPOSITIONED 

FOR RETRY. 

This message occurs if machine or system failure is de- 
tected by some portion of the IBJOB Processor. 

PATCH TABLE HAS OVERFLOWED. 

This message occurs if more than 50 table words have 
been generated because of $PATCH cards. Table words 
are generated as follows: one word is necessary for each 
vj.jij.vjxa »jaiu. aim an auuiuonai woru is necessary ror 
each patch word on the card. 

PERMANENT REDUNDANCY OR EOT WHILE READING 
ALTERNATE UNIT. 
Self-explanatory. 

PERMANENT REDUNDANCY WHILE READING CON- 
TROL CARDS. THIS P/A CANNOT BE CONTINUED. 
Self-explanatory. 

PREST CARD CKSUM ERROR, SEQUENCE 

NUMBER *****. 

This message occurs if, while processing a Prest deck, a 
check-sum error is detected. Processing will continue. 
Execution is prevented. 

PREST CARD FIELD ERROR. SEQUENCE 

NUMBER *****. 

This message occurs if, while processing a Prest deck, an 
error is detected in the field or string count. Processing 
continues. Execution is prevented. 



PREST CARD SEQ ERROR. SEQUENCE NUMBER *****. 
This message occurs if, while processing a Prest deck, an 
error is detected in the sequence of cards. Processing 
continues. Execution is prevented. 

REDUNDANCY WHILE READING ALTER CARDS. THIS 

DECK CANNOT BE PROCESSED. 

This message occurs when a read redundancy occurs 
while moving Alter cards to the system utility unit 

(SYSUT2). 

REMAINDER OF JOB DELETED. 

This message occurs if the option to delete the remainder 
of the job is chosen after machine or system failure has 
occurred. 

RETURNING TO IBSYS. 

This message occurs when the IBJOB Processor is re- 
turning control to the System Monitor. 

SCHF OPTION INVALID IF SYSINx IS DISK. PROCEED- 
ING TO NEXT P/A. 

This message occurs when the "search option" ( SCHFn ) 
is requested on a $IEDIT card and the system unit func- 
tion requested for the search is assigned to disk. 

SYSxxx IN USE. PROCEEDING TO NEXT P/A. 

This message occurs when SYSxxx has been requested 
on either a $IEDIT or $OEDIT card, and it is cur- 
rently in use due to a previous $OEDIT or $IEDIT 
card. 

SYSxxx NOT ASSIGNED. PROCEEDING TO NEXT P/A. 
This message occurs when SYSxxx has been requested 
on either a $IEDIT or $OEDIT card and no unit is 
assigned to the function. 

THIS DECK CONTROL CARD CANNOT BE PROCESSED. 

IT MUST APPEAR IN TABLE SSTAB. 

This message occurs when a recognized subsystem con- 
trol card is encountered and the SYSTM routine is not 
set up properly for the subsystem. 

THIS JOB WILL BE CONTINUED. 

This message occurs if the option to continue is chosen 
after machine or system failure has occurred. 

UNIT ****** EOT OR EOB EXIT. 

This message occurs if the system input/output editor, 
while trying to write on an input/output unit, receives 
a signal from IOCS that an end-of -buffer condition exists. 
If the unit is 1301/2302 Disk Storage, the condition is 
caused by exceeding the cylinder limits specified for 
the system function. 

UNRECOGNIZED OPTION ON ABOVE CARD. 

This message occurs when an unrecognized option is 
encountered on a $IEDIT or $OEDIT control card. The 
standard option is used. 
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The following alphabetic list contains the error mes- 
sages generated by the Fortran iv Compiler and their 
explanations where necessary. Words in a message that 
must vary from situation to situation are denoted by 
«*****» \yhgj-e asterisks actually appear as a standard 

r .1 1 .. • • -on ■ T 
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Messages which begin with variable words are 
alphabetized according to the first word following the 
variable quantity. Messages which cannot be located 
alphabetically by the first word should be sought ac- 
cording to the second word of the message. 

A DO ENDING IS MISSING OR HAS OCCURRED REFORE 
THE DO ITSELF. 

Self-explanatory. 

A DO ENDING ***** IS MISSING OR IS A NON EXEC- 
UTARLE STATEMENT. 

Violation of FORTRAN requirements for DO statement. 

Provide ending for DO; provide an executable statement 

for end of DO. 

A DO ENDING IS A NON EXECUTARLE STATEMENT, OR 
ANOTHER DO, OR A TRANSFER. 

Violation of FORTRAN requirements for DO statement. 

The DO statement must be terminated correctly. 

A DOUHLE PRECISION OR COMPLEX VARIARLE ***** 
IS BROUGHT INTO COMMON BY AN EQUIVALENCE 
STATEMENT BUT DOES NOT LIE AN EVEN NUMBER 
OF LOCATIONS FROM BEGINNING OF THAT BLOCK. 

Equivalence statement must be changed so that when 
the variable is brought in, it is an even number of posi- 
tions from the head of the block. Each double-precision 

of core storage. 
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A FORMAT ***** HAS BEEN ILLEGALLY REFERENCED 

BY A GO TO OR AN ASSIGN. 

FORTRAN does not allow a FORMAT statement to be 
referenced by a GO TO statement or an ASSIGN state- 
ment. 

A FORMULA NUMBER IS GREATER THAN 2**15 OR IS 

NOT AN INTEGER CONSTANT. 

A formula number must be an integer constant and 
must be less than or equal to 2 to the 15th power. ( The 
asterisks here indicate exponentiation). 

A FORMULA NUMBER IS NULL. 

External Formula Number is incorrect. Processor cannot 
determine value. 

AFTER OR NEAR OPERAND ***** FIND IMPROPER DE- 
LIMITER *****. 

Self-explanatory. 

A GO TO DESTINATION OR AN - ASSIGN - REFERENCE 
***** IS MISSING OR IS A NON EXECUTABLE STATE- 
MENT. 

Supply label as the object for the GO TO statement or 
provide label at the correct executable statement. 



A JOB BEGINS WITH AN END-OF-FILE OR A NON IBFTC 
CARD. 

Self-explanatory. 

ALPHABETIC CHARACTER EXPECTED AFTER A 
PERIOD. REFERENCE OPERAND *****. 
Self-explanatory. 

A NAMELIST NAME IS MISSING. 

Self-explanatory. 

A NAME BEGINS WITH A NUMERIC CHARACTER. 
Self-explanatory. 

AN ELEMENT IN THE SURSCRIPT COMBINATION IS 
MISSING OR IS ZERO FOR ARRAY *****. 
Self-explanatory. 

AN END CARD IS NOT FOLLOWED BY AN END OF FILE 
OR A CONTROL CARD - INPUT CARDS WILL RE 
IGNORED UNTIL NEXT EOF OR $ CARD. 

Self-explanatory. 

AN ERROR HAS OCCURRED TRYING TO READ IN THE 

INTERPHASE TARLES. 

Internal compiler error. Programmer should attempt 
rerun. If error persists consult system engineer. 

AN ERROR HAS OCCURRED TRYING TO WRITE OUT 

THE INTERPHASE TABLE. 

Internal compiler error. Programmer should attempt 
rerun. If error persists consult system engineer. 

AN ILLEGAL CHARACTER FOLLOWS ROUTINE NAME 

***** 

Self-explanatory. 

AN I/O STATEMENT REFERENCED A MISSING FORMAT 
OR AN ILLEGAL STATEMENT. THE REFERENCED EFN 

JO ***** 

The External Formula Number must reference a proper 
statement. The External Formula Number must be as- 
signed to the desired statement. 

APPARENT LOGICAL ERROR IN PROCESSING. 

General internal error covering a variety of possibilities. 
Consult system engineer or attempt rerun. 

ARGUMENT ***** APPEARS MORE THAN ONCE IN THE 
SAME SUBROUTINE, FUNCTION, OR ENTRY STATE- 
MENT. 

Self-explanatory. 

ARGUMENT VARIABLE ***** WAS PREVIOUSLY USED 
AS AN ENTRY POINT NAME. 
Self-explanatory. 

ARITHMETIC STATEMENT FUNCTION DEFINITIONS 
MUST APPEAR REFORE ANY OTHER EXECUTARLE 
STATEMENTS. 

Place Arithmetic Statement Function definition before 

any other executable statement. 

ARRAYS WITH MORE THAN 3 DIMENSIONS WILL BE 
ENTERED IN THE DERUG DICTIONARY AS 1 DIMEN- 
SIONAL ARRAYS. 

Self-explanatory. 

A SLASH IS MISSING AT THE BEGINNING OF THIS 
NAMELIST STATEMENT. 
Self-explanatory. 



FORTRAN IV Compiler Error Messages 127 



ASTERISK IS ILLEGAL ARGUMENT IN FUNCTION SUB- 
PROGRAM. 

Self-explanatory. 

A SUBSCRIPT, A DIMENSION, OR A PARAMETER IS 
ZERO OR GREATER THAN 32767, OR IS NOT AN IN- 
TEGER. 

A subscript, a dimension, or a parameter must be an 
integer greater than zero and less than 32767. FORTRAN 
requirement. 

A VARIABLE HAS TOO MANY ADDENDS. 
Self-explanatory. 

A VARIABLE NAME IS A NUMERIC. 
Self-explanatory. 

A ZERO COEFFICIENT IS NOT ALLOWED IN SUBSCRIPT 
OF ARRAY *****. 

If this condition occurs, a 1 is assumed as the coefficient. 

Execution is permitted. 

BUILT-IN FUNCTION NAME ***** APPEARED IN AN EX- 
TERNAL STATEMENT OR IS AN ARGUMENT TO THIS 
SUBPROGRAM AND WILL BE TREATED AS AN EX- 
TERNAL FUNCTION SUBPROGRAM. 
Self-explanatory. 

BUILT-IN OR ARITHMETIC STATEMENT FUNCTION 
NAMES CANNOT BE PASSED AS ARGUMENTS REFER- 
ENCE SYMBOL *****. 
Self-explanatory. 

BUILT-IN OR LIBRARY FUNCTION ***** HAS BEEN IN- 
CORRECTLY TYPED. SYSTEM TYPING WILL TAKE 
PRECEDENCE, 

Self-explanatory. 

COMMA MISSING AFTER THE INDEX NAME. 
Self-explanatory. 

COMMA MISSING BEFORE THE VARIABLE NAME *****. 
Self-explanatory. 

COMMA MISSING BETWEEN EQUIVALENCE GROUPS. 
Self-explanatory. 

COMMON BLOCK ILLEGALLY EXTENDED BEYOND 
ORIGIN BY EQUIVALENCE VARIABLE *****. 
Self-explanatory. 

COMMON BLOCK NAME OR NAMELIST NAME IS MISS- 
ING. 

Self-explanatory. 

COMMON OR EQUIVALENCE STATEMENT SHOULD 
APPEAR BEFORE THE FIRST DO. 
Self-explanatory. 

COMPILER EXPECTS A NUMERICAL ADDEND FOL- 
LOWING THE + OR - SIGN IN THE SUBSCRIPT ELE- 
MENT OF THE ARRAY *****. 
Self-explanatory. 

COMPILER EXPECTS A NUMERICAL FIELD. 
Self-explanatory. 

COMPILER EXPECTS AN INTEGER VARIABLE NAME 
AS ONE OF THE SUBSCRIPT ELEMENTS OF THE 
ARRAY *****. 

Self-explanatory. 

COMPILER EXPECTS Nl, N2, N3. 

Programmer must provide 3 branches for Arithmetic 
IF statement. Consult section on IF statement. 

COMPILER EXPECTS SUBROUTINE NAME AFTER THE 
WORD CALL. NUMERICS OR PUNCTUATION FOUND 
INSTEAD. 

Self-explanatory. 



DATA STATEMENT. DATA FOR ARGUMENT VARIABLE 
***** DATA NOT COMPILED. 
Self-explanatory. 

DATA STATEMENT. DATA FOR ASF ARGUMENT ***** 
DATA NOT COMPILED. 

Data for the Arithmetic Statement Function must be 

provided. 

DATA STATEMENT. DATA FOR BLANK-COMMON VARI- 
ABLE ***** DATA NOT COMPILED. 
Self-explanatory. 

DATA STATEMENT. DATA FOR COMMON VARIABLE 
***** in NON-BLOCK DATA PROGRAM. FORTRAN IV 
LANGUAGE VIOLATION BUT DATA COMPILED. 

Self-explanatory. 

DATA STATEMENT. DATA FOR ILLEGAL VARIABLE 
***** DATA NOT COMPILED. 
Self-explanatory. 

DATA STATEMENT. DATA FOR NON-COMMON VARI- 
ABLE ***** IN BLOCK-DATA PROGRAM. DATA NOT 
COMPILED. 

Self-explanatory. 

DATA STATEMENT ***** DOES NOT END WITH /. 
Self-explanatory. 

DATA STATEMENT FOR GROUP ***** ILLEGAL PUNC- 
TUATION FOLLOWING NAME ***** TREATED AS 
COMMA. 

Self-explanatory. 

DATA STATEMENT ***** GROUP ***** EMPTY VARI- 

A UT T7 T TOT" 
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Self-explanatory. 

DATA STATEMENT ***** GROUP ***** ERROR IN SUB- 
SCRIPT FOR NAME *****. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** IMPROPER OR 
MISSING PARAMETER FOR DO ON ***** PARAMETER 
ASSUMED TO BE 1. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
ILLEGAL ALPHABETIC LITERAL *****. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
ILLEGAL PERIOD PRECEDING LITERAL. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
ILLEGAL PUNCTUATION TAKEN AS COMMA. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
ILLEGAL ZERO COUNT FOR - H - FIELD. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
INCORRECT LOGICAL CONSTANT TAKEN AS .FALSE. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
INCORRECT LOGICAL CONSTANT TAKEN AS .TRUE. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
MISSING PERIOD. INSERTED AT END OF LOGICAL 
CONSTANT. 

Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST 
MISSING PUNCTUATION. COMMA ASSUMED. 
Self-explanatory. 
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DATA STATEMENT ***** GROUP ***** LITERAL LIST 
REPEAT COEFFICIENT NOT INTEGRAL. TAKEN AS 
ZERO, 

Self-explanatory. 

DATA STATEMENT ***** GROUP ***** LITERAL LIST. 
SUPERFLUOUS PUNCTUATION IGNORED. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** MISSING COMMA 
ASSUMED FOLLOWING NAME *****. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** MISSING RIGHT 
PARENTHESIS INSERTED AFTER SPECIFICATION OF 
DO ON *****. 

Self-explanatory. 

DATA STATEMENT ***** GROUP ***** SUPERFLUOUS 
PUNCTUATION IGNORED FOLLOWING NAME *****. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** UNPAIRED LEFT 
PARENTHESES IGNORED. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** UNPAIRED 
RIGHT PARENTHESES IGNORED FOLLOWING NAME 
***** 

Self-explanatory. 

DATA STATEMENT ***** GROUP ***** VARIABLE 
NAME ***** APPEARS ONLY IN DATA STATEMENT. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** VARIABLE 
NAME ***** IS AN ARGUMENT TO THIS PROGRAM. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** VARIABLE 
NAME TO LONG TRUNCATED TO *****. 
Self-explanatory. 

DATA STATEMENT ***** GROUP ***** VARIABLE 
NAME ***** STARTS WITH NUMERIC CHARACTER AND 
IS IGNORED. 

Self-explanatory. 

DATA STATEMENT. IMPLIED-DO NESTING LEVEL 
EXCEEDS SEVEN. ALL LEVELS ABOVE SEVENTH 
IGNORED. 

Self-explanatory. 

DATA STATEMENT. INITIAL OR FINAL DO-INDEX 
VALUES OUT OF RANGE OF DIMENSIONS FOR 
VARIABLE *****. 

Self-explanatory. 

DATA STATEMENT LITERAL LIST LONGER THAN 
VARIABLE LIST. 

Self-explanatory . 

DATA STATEMENT. NO SUBSCRIPT CORRESPONDING 
TO DO INDEX ***** FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT. NO DO INDEX CORRESPONDING 
TO SUBSCRIPT ***** FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT. SHORT-LIST VARIABLE ***** IN DO. 
Self-explanatory. 

DATA STATEMENT. SUBSCRIPTS OUT OF RANGE OF 
DIMENSIONS FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT. TYPE DISCREPANCY. COMPLEX 
DATA FOR VARIABLE *****. 
Self-explanatory. 



DATA STATEMENT. TYPE DISCREPANCY DOUBLE PRE- 
CISION DATA FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT. TYPE DISCREPANCY INTEGER 
DATA FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT. TYPE DISCREPANCY LOGICAL 
DATA FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT. TYPE DISCREPANCY 'REAL' DATA 
FOR VARIABLE *****. 
Self-explanatory. 

niTi OTITT'UrMT TTXTCTTT>C/~'T3TI3n , C , I"» X/AUTAuTXT ***** 
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IN DO. 

Self-explanatory. 

DATA STATEMENT VARIABLE LIST LONGER THAN 
LITERAL LIST. 

Self-explanatory. 

DATA STATEMENT VARIABLE SUBSCRIPTS OUTSIDE 
DO FOR VARIABLE *****. 
Self-explanatory. 

DATA STATEMENT VARIABLE ***** WITH ONLY CON- 
STANT SUBSCRIPTS IN DO. 
Self-explanatory. 

DELIMITER DOES NOT FOLLOW SUBSCRIPTED VARI- 
ABLE *****. 

Self-explanatory. 

DIFFERENT RESULTS FOR THE SAME SCAN: LOGICAL 
ERROR. 

Internal compiler error. Programmer should attempt 
rerun. If error persists consult system engineer. 

DOLLAR SIGNS LEGAL ONLY FOR ERROR RETURNS 
IN SUBROUTINE CALLS. 
Self-explanatory. 

DO REFERENCE MISSING OR WRONG PUNCTUATION 
WITHIN A DO. 

Self-explanatory. 

DO'S INCORRECTLY NESTED, NO FURTHER CHECK- 
ING WILL BE DONE FOR THIS ERROR IN SUBSEQUENT 
DO-NEST. 

First DO entered must be last DO satisfied. 

DOTAG/MAIN FILES SEQUENCE ERROR. 

Internal compiler error. Programmer should attempt 
rerun. If error persists, consult system engineer. 

DOUBLE OPERATOR FOLLOWING SYMBOL ***** ILLE- 
GAL PUNCTUATION *****. 
Self-explanatory. 

DUPLICATE EFN. 

Two statements cannot have the same External Formula 
Number. 

EFN IS ZERO OR GREATER THAN 32,767 OR IS NOT AN 
INTEGER. 

The External Formula Number must be an integer 

greater than zero or less than 32767. 

EFN MISSING. 

An External Formula Number must be provided. 

EMPTY STATEMENT - PARAMETERS OR ARGUMENT 
LIST MISSING. 

The statement is not recognized in its present form. 
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ENTRY STATEMENT WITHIN A DO NEST. STATEMENT 
IGNORED. 

Self-explanatory. 

EOB OR REFERENCE IOCS MESSAGE FOR DOTAG/ 

MAIN FILES. 

IOCS error return. Internal error can be an end-of- 
buffer condition or an IOCS error. Consult system engi- 
neer or attempt rerun. 

EQUIVALENCE GROUPS REQUIRE TWO VARIABLES. 
Self-explanatory. 

ERROR IN A COMPLEX LITERAL - SCAN WILL RESUME 
AT THE CHARACTER FOLLOWING THE RIGHT PAREN- 
THESIS, IF ANY, OR WILL STOP IF NO RIGHT PAREN- 
THESIS IS FOUND. 
Self-explanatory. 

EXPONENT FIELD TOO LONG - ONLY THE FIRST TWO 
SIGNIFICANT DIGITS HAVE BEEN KEPT. 
Self-explanatory. 

FOLLOWING SYMBOL ***** SYNTACTICAL USE OF 
OPERATOR ***** IS INCORRECT. 
Self-explanatory. 

FOLLOWING SYMBOL ***** THERE IS NON-LOGICAL 
OPERAND IN A LOGICAL EXPRESSION. 
Self-explanatory. 

FORMAT STATEMENT ***** CHARACTER ***** ILLEGAL 
IN CONTEXT. 

Self-explanatory. 

FORMAT STATEMENT ***** EXTENDS BEYOND RIGHT 
PARENTHESIS WHICH MATCHES OPENING PAREN- 
THESIS. 

Self-explanatory. 

FORMAT STATEMENT ***** ILLEGAL CHARACTER 

***** 

Self-explanatory. 

FORMAT STATEMENT ***** NO NUMBER PRECEDING 
SCALE FACTOR P. 

Self-explanatory. 

FORMAT STATEMENT ***** NO NUMBER PRECED- 
ING X. 

Self-explanatory. 

FORMAT STATEMENT ***** NO OPENING PAREN- 
THESIS. 

Self-explanatory. 

FORMAT STATEMENT ***** NOT PRECEDED BY NUM- 
BER. 

Self-explanatory. 

FORMAT STATEMENT ***** NUMBER ASSOCIATED 
WITH ***** EXCEEDS 132. 
Self-explanatory. 

FORMAT STATEMENT ***** NUMBER FOLLOWING IN 
D, E OR F FIELD IS GREATER THAN NUMBER PRE- 
CEDING. 

Self-explanatory. 

FORMAT STATEMENT ***** PARENTHESES DO NOT 
BALANCE. 

Self-explanatory. 

FORMAT STATEMENT ***** P SCALING FACTOR TOO 
LARGE. 

Self-explanatory. 

FORMAT STATEMENT ***** TOO MANY NESTED LEFT 
PARENTHESES. 

Self-explanatory. 



FORMAT STATEMENT ***** ZERO - H - SPECIFICATION 
ILLEGAL. COUNT ASSUMED TO BE ONE. 
Self-explanatory. 

FUNCTION ***** IS USED IN A SUBROUTINE CONTEXT. 
Self-explanatory. 

FUNCTION NOT USED IN AN INPUT LIST OR AT THE 

LEFT OF AN EQUAL SIGN. 

Violation of FORTRAN requirements. Function must be 
used in input list or at the left of an equal sign. 

FUNCTION OR SUBROUTINE ***** CALLS ITSELF. 
Self-explanatory. 

FUNCTION NAME DOES NOT APPEAR ON LEFT OF 
EQUALS SIGN. 

Self-explanatory. 

HIGH ORDER POSITION OF VARIABLE ***** IS NOT 
AN EVEN NUMBER OF WORDS FROM BEGINNING OF 
COMMON BLOCK ******. 

Compiler requirements. Adjust high order position of 

variable to conform with message. 

HOLLERITH LITERALS ARE PERMITTED ONLY AS 
DIRECT ARGUMENTS IN CALL STATEMENTS. 
Self-explanatory. 

IBFTC HAS BEEN GIVEN CONTROL WITH A NON-IBFTC 

CARD. 

Message can occur through a machine error or an internal 
compiler error. Programmer should attempt rerun. If 
error persists consult system engineer. 

ILLEGAL CHARACTER AFTER FORMULA NUMBERS 

■lVJlWyi.Uli.L-/. 

An external formula number must not be followed by 
a non-numeric character. 

ILLEGAL CHARACTER BEFORE FORMULA NUMBERS 
TREATED AS A LEFT PARENTHESIS. 
Self-explanatory. 

ILLEGAL CHARACTER BEFORE VARIABLE NAME. 
Self-explanatory. 

ILLEGAL CHARACTER IN A NUMBERIC FIELD. 
Self-explanatory. 

ILLEGAL CHARACTER ***** OCTAL, TREATED AS A 
BLANK. 

Self-explanatory. 

ILLEGAL CHARACTER OR PUNCTUATION *****. 
Self-explanatory. 

ILLEGAL CHARACTER OR PUNCTUATION. 

Self-explanatory. 

ILLEGAL DO PARAMETER. 
Self-explanatory. 

ILLEGAL FORMAT REFERENCE 
Self-explanatory. 

ILLEGAL OR MISSING PUNCTUATION. 

Self-explanatory. 

ILLEGAL PUNCTUATION DETECTED IN SOME SUB- 
SCRIPT ELEMENT FOR THE ARRAY ***** OR NUM- 
BER OF SUBSCRIPTS DOES NOT AGREE WITH DIMEN- 
SIONALITY. 

Self-explanatory. 

ILLEGAL PUNCTUATION IN THIS STATEMENT. 
Self-explanatory. 

ILLEGAL TRANSFER FROM OUTER DO TO INNER DO. 
Self-explanatory. 
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ILLEGAL TRANSFER INTO DO NEST FROM OUTSIDE 
ITS RANGE. 

Self-explanatory, 

ILLEGAL TRUE CONDITION FOR THIS LOGICAL IF. 
Programmer has given an illegal true condition for IF 
statement. Violation of FORTRAN language require- 
ments. 

ILLEGAL USE OF A PERIOD NEAR SYMBOL *****. 
Self-explanatory. 

ILLEGAL UNIT REFERENCE. 
Self-explanatory. 
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VARIABLE OR EXPRESSION. 

A logical variable cannot be preceded by + or — sign 
in a logical expression. 

ILLEGAL USE OF EXPONENTIAL OPERATOR. 
Self-explanatory. 

ILLEGAL USE OF THE DELIMITER ***** EXISTS. 
Self-explanatory. 

INCOMPLETE STATEMENT - FORMULA NUMBERS 
MISSING. 

Self-explanatory. 

INCOMPLETE STATEMENT - VARIABLE MISSING. 
Self-explanatory. 

INCONSISTENT RECURRENCE IN EQUIVALENCE 
STATEMENT OF VARIABLE *****. 
Self-explanatory. 

INCONSISTENT USAGE. ***** CANNOT BE USED AS A 
SUBROUTINE NAME. 
Self-explanatory. 

INCONSISTENT USAGE OF ENTRY NAME *****, 
Self-explanatory. 

INCORRECT EFN IN COLUMNS 1 to 6. 

Provide correct External Formula Number. 

INCORRECT NUMBER OF ARGUMENTS FOR BUILT-IN 
FUNCTION *****. 

Self-explanatory. 

INCORRECT PUNCTUATION PRECEDES OR FOLLOWS 
NAME *****. 

Self-explanatory. 

INPUT ERROR-THE FOLLOWING CARD WILL NOT 
BE PROCESSED. 

Check input deck to eliminate faulty cards. 

INTEGER GREATER THAN 32767. 

Violation of FORTRAN language requirements. 

INTEGER GREATER THAN 2**35-1. 

Error in fixed-point arithmetic. Violation of FORTRAN 
language requirements. Asterisks indicate exponentiation. 

INVALID ENTRY IN TABLE *****. 

Internal compiler error. Programmer should attempt to 
rerun program. If error persists, consult system engineer. 

***** IS A NON LOGICAL OPERAND IN A LOGICAL EX- 
PRESSION. 

Self-explanatory. 

LEFT PARENTHESIS EXPECTED AFTER IF. 
Self-explanatory. 



LIBRARY FUNCTION NAME ***** HAS BEEN TYPED AS 
EXTERNAL AND INCONSISTENTLY WITH SYSTEM 
TYPING. USER TYPING WILL TAKE PRECEDENCE. 
Self-explanatory. 

LIBRARY FUNCTION NAME ***** HAS BEEN TYPED IN- 
CONSISTENTLY WITH SYSTEM TYPING. SYSTEM 
TYPING WILL TAKE PRECEDENCE. 
Self-explanatory. 

MISSING LEFT PARENTHESIS BEFORE FORMULA 
NUMBERS. 

Self-explanatory. 

MISSING PARAMETER WITHIN A DO. 
Self-explanatory. 

MISSING PUNCTUATION OR ILLEGAL USE OF A 
DELIMITER. 

Self-explanatory. 

NEAR SYMBOL ***** AN ARGUMENT TO AN ARITH- 
xMETIC STATEMENT FUNCTION DEFINITION BEGINS 
WITH A NUMERIC OR PUNCTUATION CHARACTER. 
Self-explanatory. 

NO CLOSING RIGHT PARENTHESIS OR ILLEGAL 
CHARACTER ENDS SUBSCRIPT COMBINATION OF THE 
ARRAY ***** OR NUMBER OF SUBSCRIPTS DOES NOT 
AGREE WITH DIMENSIONALITY. 
Self-explanatory. 

NO FORMULA NUMBER IN THIS GO TO STATEMENT. 
Self-explanatory. 

NO MORE TABLE SPACE AVAILABLE. 

Program cannot be accommodated. Segment programs 
into subprograms. 

NUMBER OF SUBSCRIPTS FOR EQUIVALENCED ARRAY 
***** WRONG. 

Self-explanatory. 

NUMERICAL VARIABLE NAME IN THE STATEMENT. 
Self-explanatory. 

OCTAL NUMBER MORE THAN FIVE DIGITS. 
Self-explanatory. 

ODD SEPARATION BETWEEN EQUIVALENCED DOU- 
BLE-PRECISION OR COMPLEX VARIABLES ***** AND 
***** 

Compiler requirement. Programmer must maintain an 
even separation. 

OPERATOR MISSING BEFORE OR AFTER OPERAND 
Self-explanatory, 

***** OPTION NOT IN THE DICTIONARY OR WRONG 
PUNCTUATION. 

Self-explanatory. 

OPTIONAL ERROR RETURN IS EITHER LARGER THAN 
32,767 OR NOT AN INTEGER. 

Violation of FORTRAN language. Programmer should 

correct External Formula Number. 

OVERFLOW IN THIS FLOATING POINT NUMBER. 
Self-explanatory. 

PARENTHESES ARE ILLEGAL. 
Self-explanatory. 

PARENTHESES DO NOT BALANCE. 
Self-explanatory. 
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PUNCTUATION MISSING OR INCOMPLETE STATE- 
MENT. 

Self-explanatory. 

REDUNDANT COMMA. 

Self-explanatory. 

REDUNDANT COMMA IN FORMULA NUMBERS. 
Self-explanatory. 

REDUNDANT COMMA IN THIS STATEMENT. 
Self-explanatory. 

REDUNDANT COMMA OR ILLEGAL PUNCTUATION. 

Self-explanatory. 

REDUNDANT COMMA OUTSIDE THE FORMULA NUM- 
BERS. 

Self-explanatory. 

REDUNDANT PARENTHESIS IN THIS STATEMENT. 
Self-explanatory. 

RIGHT AND LEFT PARENTHESES DO NOT BALANCE. 
Self-explanatory. 

RIGHT PARENTHESIS MISSING AFTER FORMULA 
NUMBERS OR INCOMPLETE STATEMENT. 
Self-explanatory. 

RIGHT PARENTHESIS MISSING FOR THE ARRAY *****. 
Self-explanatory. 

RIGHT PARENTHESES OR COMMA EXPECTED AFTER 
A DOLLAR SIGN. 

Self-explanatory. 

***** SHOULD BE FOLLOWED BY LEFT PARENTHESIS 
OR EQUALS SIGN. 

Self-explanatory. 

***** SHOULD BE PRECEDED BY COMMA OR LEFT 
PARENTHESIS OR FOLLOWED BY COMMA OR RIGHT 
PARENTHESIS. 

Self-explanatory. 

STATEMENT ILLEGAL IN THIS CONTEXT. STATEMENT 
IGNORED. 

Self-explanatory. 

SUBARG TABLE MISSING AT THE BEGINNING OF 

PHASE B. 

Internal compiler error. The subroutine argument table 
is functioning incorrectly. Programmer should attempt a 
rerun. If error persists, consult system engineer. 

SUBPROGRAM NAME ***** USED PREVIOUSLY AS 
VARIABLE OR COMMON BLOCK NAME. 
Self-explanatory. 

SUBROUTINE, FUNCTION, OR ENTRY NAME ***** 
CANNOT BE SAME AS DECK NAME. 
Self-explanatory. 

SUBROUTINE NAME ***** USED PREVIOUSLY AS 
VARIABLE OR COMMON BLOCK NAME. 
Self-explanatory. 

SUBSCRIPTS ARE NOT PERMITTED IN ARITHMETIC 
STATEMENT FUNCTION DEFINITIONS. 
Self-explanatory. 

SUBSCRIPTS NOT PERMITTED IN A NAMELIST FOR 
THE ARRAY *****. 
Self-explanatory. 

SYMBOL BEGINNING WITH ***** TRUNCATED TO SIX 
CHARACTERS. 

Self-explanatory. 



SYMBOL FOLLOWING ***** UNIDENTIFIABLE. 
Self-explanatory. 

SYMBOL LEFT OF EQUALS ILLEGAL OR NON- 
EXISTENT. 

Self-explanatory. 

THE ADDEND ***** IS NOT NUMERICAL. 
Self-explanatory. 

THE ADJUSTABLE DIMENSION ***** HAS BEEN DIMEN- 
SIONED. 

Self-explanatory. 

THE ADJUSTABLE DIMENSION ***** IS NOT AN ARGU- 
MENT OF THIS PROGRAM. 

Calling program must supply value for adjustable dimen- 



THE ADJUSTABLE DIMENSION ***** MUST NOT BE 
DIMENSIONED. 

Self-explanatory. 

THE ADJUSTABLE DIMENSION ***** IS NOT AN IN- 
TEGER VARIABLE. 
Self-explanatory. 

THE ARRAY ***** HAS ADJUSTABLE DIMENSION(S). 
Self-explanatory. 

THE ARRAY ***** HAS MORE THAN 7 DIMENSIONS. 
Self-explanatory. 

THE ARRAY ***** HAS NO DIMENSION. 



THE ARRAY ***** HAS NOT BEEN DIMENSIONED. 
Self-explanatory. 

THE ARRAY ***** IN COMMON HAS AN ADJUSTABLE 
DIMENSION. 

Self-explanatory . 

THE ARRAY NAME IN COMMON ***** HAS A VARIABLE 
DIMENSION *****. 
Self-explanatory. 

THE ARRAY ***** HAS AN ADJUSTABLE DIMENSION 
***** IS NOT AN ARGUMENT OF THIS PROGRAM. 
Illegal FORTRAN construction. 

THE COMMON BLOCK ***** IS EMPTY. 

Area assigned to COMMON has not been utilized. 

THE COMMON BLOCK NAME ***** HAS BEEN USED 
AS A NAMELIST OR ROUTINE NAME. 
Self-explanatory. 

THE COMPILER EXPECTS A FORMULA NUMBER. 
Self-explanatory. 

THE COMPILER EXPECTS A NUMERICAL FIELD IN- 
STEAD OF THE VARIABLE *****. 
Self-explanatory. 

THE COMPILER EXPECTS A VARIABLE NAME AFTER 
THE WORD -TO-. 
Self-explanatory. 

THE COMPILER EXPECTS END OF STATEMENT. 
EXTRANEOUS CHARACTERS IGNORED. 

Self-explanatory. 

THE COMPILER EXPECTS THE WORD - TO - AFTER 
THE FORMULA NUMBER. 
Self-explanatory. 
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THE END OF DIMENSION PRODUCT TABLE HAS 
ILLEGALLY BEEN REACHED. LOGICAL ERROR. 

Tri^orria I /trim nil or orrnr T^ri-irri-Qn-iTYior cnrm «n affomnf q 

rerun. If error persists, consult a system engineer. 

THE INDEX NAME ***** MUST BE A VARIABLE. 
Self-explanatory. 

THE INDEX NAME ***** MUST NOT BE AN ADJUSTA- 
BLE DIMENSION. 

Self-explanatory. 

THE LEFT PARENTHESIS IS ILLEGAL AS A NAMELIST 
STATEMENT. 

Self-explanatory. 

THE NAME ***** HAS ALREADY APPEARED IN A DE- 
CLARATIVE STATEMENT. 
Self-explanatory. 

THE NAME ***** HAS ALREADY APPEARED IN AN EX- 
TERNAL STATEMENT. 
Self-explanatory. 

THE NAME ***** HAS ALREADY BEEN USED AS A 
VARIABLE IN AN EXECUTABLE OR DATA, OR NAME- 
LIST STATEMENT. 
Self-explanatory. 

THE NAME ***** HAS BEEN USED AS NAMELIST OR 
COMMON BLOCK NAME. 
Self-explanatory. 

THE NAME ***** IS A ROUTINE OR NAMELIST NAME. 
Self-explanatory. 

THE NAME ***** IS NOT A VARIABLE NAME. 
Self-explanatory. 

THE NAME ***** IS THE NAME OF THIS SUBROUTINE. 
Self-explanatory. 

THE NAMELIST NAME ***** HAS ALREADY BEEN USED. 
Self-explanatory. 

THE NAMELIST ***** HAS NO LIST OF VARIABLES. 
Self-explanatory. 

THE PRODUCT OF CONSTANT DIMENSIONS IS 

GREATER THAN 2**15. 

Violation of FORTRAN language requirements. Aster- 
isks indicate exponentiation. 

THE PRODUCT OF CONSTANT DIMENSIONS IS ZERO. 
Violation of FORTRAN requirements. 

THE PROGRAM SHOULD END WITH A TRANSFER, A 
RETURN HAS BEEN GENERATED. 

Programmer should provide transfer instruction. 

THE STATEMENT WITH EFN ***** CANNOT BE 
REACHED. 

Statement number ***** cannot be reached because of 

program construction. 

THE SUBSCRIPTED VARIABLE ***** IS NOT AN ARRAY 

NAME. 

Self-explanatory. 

THE SYMBOL ***** AND ITS SUBSCRIPT OR ARGUMENT 
LIST SHOULD BE FOLLOWED BY AN EQUALS SIGN. 
Self-explanatory. 

THE SYMBOL BEGINS WITH A NUMERICAL 

CHARACTER. 

Violation of FORTRAN language requirements. 

THE SYMBOL ***** CANNOT PRECEDE ITS USE AS 
ARITHMETIC STATEMENT FUNCTION NAME IN AN 
ASF DEFINITION EXCEPT IN A TYPE STATEMENT. 

An arithmetic statement function must precede any 
executable statement. A symbol can precede an Arith- 
metic statement function definition only in a TYPE 
statement. 



THE SYMBOL ***** HAS PREVIOUSLY APPEARED IN 
A STATEMENT BEFORE APPEARING IN AN ARGU- 
MENT LIST. INSTRUCTIONS COMPILED MAY BE IN- 
CORRECT 

Self-explanatory. 

THE SYMBOL ***** WAS USED PREVIOUSLY AS AN 
ADJUSTABLE DIMENSION FUNCTION, SUBROUTINE, 
OR NAMELIST NAME. 
Self-explanatory. 

THE TYPE OF THE NAME ***** IS INCONSISTENT 
WITH A PREVIOUS DEFINITION. 
Self-explanatory. 

THE VARIABLE ***** BEGINS WITH A NUMERIC CHAR- 
ACTER. 

Self-explanatory. 

THE VARIABLE ***** HAS ALREADY BEEN DIMEN- 
SIONED. 

Self-explanatory. 

THE VARIABLE ***** HAS ALREADY BEEN USED IN 
COMMON. 

Self-explanatory. 

THE VARIABLE ***** IS AN ADJUSTABLE DIMENSION. 
Self-explanatory. 

THE VARIABLE ***** IS NOT AN INTEGER OR IS AN 

ARRAY. 

The Programmer should provide a nonsubscripted in- 
teger variable to conform with this message. 

THE VARIABLE ***** MUST BE PRECEDED BY A 
COMMA. 

Self-explanatory. 

THE VARIABLE NAME ***** HAS APPEARED AS AN 
ARGUMENT. 

Self-explanatory. 

THE VARIABLE NAME ***** HAS BEEN USED AS A 
NAMELIST NAME. 

Self-explanatory. 

THE VARIABLE NAME ***** HAS BEEN USED AS A 
ROUTINE NAME. 

Self-explanatory. 

THE VARIABLE NAME ***** IS AN ADJUSTABLE DI- 
MENSION. 

Self-explanatory. 

THE VARIABLE NAME ***** IS USED IN A FUNCTION 
CONTEXT. 

Self-explanatory. 

THERE IS AN ILLEGAL OR REDUNDANT PUNCTUA- 
TION IN THIS STATEMENT. 
Self-explanatory. 

THERE IS A REDUNDANT PUNCTUATION IN THE 
ARRAY *****. 

Self-explanatory. 

THERE IS A SUPERFLUOUS COMMA IN THIS STATE- 
MENT. 

Self-explanatory. 

THERE IS A TRANSFER TO THE STATEMENT ITSELF. 
Self-explanatory. 

THIS NAME ***** HAS BEEN USED AS A ROUTINE 
NAME. 

Self-explanatory. 

THIS STATEMENT CANNOT BE REACHED. 

Programmer is notified of all statements which are 
isolated through program logic. 
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THIS STATEMENT IS EMPTY. 

Programmer should complete statement. Compiler ex- 
pects a full statement. 

THIS VARIABLE ***** HAS BEEN USED IN AN EXECU- 
TABLE-DATA-NAMELIST STATEMENT OR AS ADJUST- 
ABLE DIMENSION. 
Self-explanatory. 

TOO MANY CONTINUATION CARDS FOR THIS STATE- 
MENT. 

Self-explanatory. 

TOO MANY RIGHT PARENTHESES. 
Self-explanatory. 

fnim TTiTrn-ni"! /~* a tjt^o tt"/-\t> tttio t/-^t> 

i vvu iur iij vj/\i\i_vo run 1x110 jvjd, 
Self-explanatory. 

TYPES COMBINED ILLEGALLY. 
Self-explanatory. 

TYPES COMBINED ILLEGALLY BY AN EQUAL SIGN. 
Self-explanatory. 

TYPES COMBINED ILLEGALLY FOR EXPONENTIATION. 
Self-explanatory. 

UNDERFLOW IN THIS FLOATING POINT NUMBER. 
Violation of FORTRAN requirements. 

UNDIMENSIONED VARIABLE ***** IS SUBSCRIPTED IN 
AN EQUIVALENCE STATEMENT. *****. 

An undimensioned variable cannot be subscripted in an 

equivalence statement. 

UNEXPECTED END CONDITION. 

Internal compiler error. Programmer should attempt re- 
run. If error persists consult system engineer. 

UNEXPECTED END IN TABLE *****. 

Internal compiler error. Programmer should attempt re- 
run. If error persists, consult system engineer. 

UNEXPECTED END MARK. 
Self-explanatory. 

UNEXPECTED END OF CONSTANT TABLE. 

Internal compiler error. Programmer should attempt re- 
■ run. If error persists, consult system engineer. 



UNEXPECTED END OF DO PUSHDOWN LIST TABLE. 
Internal compiler error. Programmer should attempt re- 
run. If error persists, consult system engineer. 

UNEXPECTED END OF EFN TABLE. 

Internal compiler error. Programmer should attempt re- 
run. If error persists, consult system engineer. 

UNEXPECTED ENTRY IN THE CONVERT ROUTINE. 

Internal compiler error. Programmer should attempt re- 
run. If error persists, consult system engineer. 

UNEXPECTED EOF READING DOTAG/MAIN FILES. 

Internal compiler error. Programmer should attempt re- 
run. If error persists, consult system engineer. 

UNRECOGNIZABLE STATEMENT IGNORED. 

Compiler has not been able to locate statement in its 
dictionary. The statement is ignored in this case. 

VARIABLES ***** AND ***** IN DIFFERENT COMMON 
BLOCKS ARE ILLEGALLY EQUIVALENCED. 
Self-explanatory. 

VARIABLES ***** AND ***** IN SAME COMMON BLOCK 
ARE INCONSISTENTLY EQUIVALENCED. 

Self-explanatory. 

\74mART fc ***** Awn ***** ttu cAX/fTT 1 rn^jxiAM tit nnv 

CONSISTENTLY BUT REDUNDANTLY EQUIVALENCED. 
S elf -explanatory . 

WRONG DO INDEX. 

Self-explanatory. 

WRONG PUNCTUATION OR STATEMENT INCORRECTLY 
WRITTEN. 

Self-explanatory. 

WRONG PUNCTUATION OR TOO MANY PARAMETERS 
FOR THIS DO. END OF STATEMENT IGNORED. 
Self-explanatory. 

ZERO - H - SPECIFICATION ILLEGAL COUNT ASSUMED 
TO BE ONE. 

The numeric value preceding the H-conversion speci- 
fication must not be zero. 
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COBOL Compiler Error Messages 



The following alphabetic list contains the error mes- 
sages generated by the cobol Compiler. Messages 
involving the linkage-mode language and compile-time 
debugging language are included in this list, since they 
are so closely connected to cobol programming. 

In addition to the error message, a card number cor- 
responding to the number of a card in the deck will also 
be generated. This number does not necessarily mean 
that the error occurred on that particular card, but 
simply means that the error occurred in that general 
area. If the Compiler for some reason cannot determine 
the number of a card, it lists the number as either 
0000 or 9999. 

Words in a message that must vary from situation to 
situation are denoted by "*****." Where asterisks actu- 
ally appear as a standard part of a message, the condi- 
tion is specifically noted. In a case where the Compiler 
inserts variable information at the beginning of a 
message, the message is listed alphabetically by the 
next nonvariable word. For this reason, if a cobol error 
message cannot be found alphabetically based on the 
first word, the programmer should use the second, and 
in exceptional cases, the third word. 

All references are to the publication IBM 7090/7094 
IBSYS Operating System: COBOL Language, Form 
C28-6391. 

Note: There is only one possible map assembly error 
message that can result from a source deck error when 
the source deck is in cobol. This is: "location field 
format error." If such a source deck error results in 
any other map message, the programmer should consult 
a system engineer. 

A SPACE SHOULD SEPARATE A SUBSCRIPTED NAME 
FROM THE FOLLOWING LEFT PARENTHESIS. SPACE 
IS ASSUMED. 

Self-explanatory. 

'ACCEPT MAY ONLY BE FOLLOWED BY A DATA-NAME. 
NOTHING DONE. 

See the ACCEPT verb. 

ALL CHARACTERS ACCEPTED FOR ***** MUST BE 
NUMERIC. 

See the ACCEPT verb. 

ALPHABETIC CLASS SPECIFIED FOR ***** IGNORED 
SINCE ITEM IS EXTERNAL DECIMAL. 

ALPHABETIC CLASS cannot be specified for external 

decimal (NUMERIC DISPLAY) items. 

ALPHABETIC OR ALPHANUMERIC CLASS SPECIFIED 
FOR ***** IGNORED SINCE ITEM IS INTERNAL 
DECIMAL. 

Internal decimal (NUMERIC COMPUTATIONAL) 
items cannot be alphabetic or alphanumeric. 



ALTER AT ***** DISALLOWED SINCE IT IS NOT SINGLE 
GO TO SENTENCE. 

See the ALTER verb. 

ALTER REFERENCE INCORRECT ***** IS NOT A ***** 
NOTHING DONE. 

There has been incorrect use of the ALTER verb. The 

ALTER statement is ignored. 

***** AND ***** HAVE NO CORRESPONDING SUB- 
FIELDS. NO ACTION STATEMENTS GENERATED FOR 
THIS PAIR. 

See the MOVE CORRESPONDING verb. 

ARGUMENT NUMBER ***** MAY NOT APPEAR IN A DIS- 
PLAY STATEMENT. SPACE ASSUMED INSTEAD. 
See the DISPLAY verb. 

ARITHMETIC PHRASES IN CONDITIONAL EXPRES- 
SIONS MAY NOT CONSIST OF MORE THAN 500 OPER- 
ATORS AND OPERANDS. EXPRESSION DELETED SINCE 
LIMIT EXCEEDED. 

Break expression into smaller parts. 

*****, ASSOCIATED WITH OCCURS . . . DEPENDING ON 

. . . , IS AN IMPROPER DATA ITEM. CLAUSE IGNORED. 

The data-name is required to be a positive integer 

greater than zero. See OCCURS clause of the data-item 

description. 

*****, ASSOCIATED WITH REDEFINES OR OCCURS . . . 

DEPENDING ON . . . , IS AN IMPROPER DATA ITEM. 

CLAUSE IGNORED. 

See the REDEFINES and OCCURS clauses of the data- 
item description. 

ATTEMPTED DIVISION BY ZERO BYPASSED. RESULT 
TAKEN TO BE ZERO. 

Division by zero is mathematically undefined. 

BINARY COMPUTATIONAL USAGE OF ***** INCOMPAT- 
IBLE WITH BCD RECORDING MODE FOR THIS FILE. 
The record must agree with the mode specifications. 

BINARY RECORDING MODE SPECIFICATION OF FILE 

***** ASSIGNED TO CARD UNIT IS NOT PERMITTED. 

Cards coming from the card reader must not be in binary. 

BLOCK SIZE (***** COMPUTER WORDS) SPECIFIED 
FOR FILE ***** IS NOT A MULTIPLE OF RECORD SIZE 
(***** COMPUTER WORDS). BLOCK SIZE CHANGED TO 
***** COMPUTER WORDS. 

This message indicates that the block size and the record 
size are inconsistent. See the BLOCK CONTAINS and 
RECORD CONTAINS clauses. 

BLOCKING OF DISTINCT RECORD TYPES OF DIFFER- 
ING SIZES, WITHOUT COUNT CONTROL, IN FILE ***** 
IS NOT PERMITTED. FILE IS SET UNBLOCKED. 
See BLOCK clause of file description entry. 

***** CANNOT BE SUBSCRIPTED. SCAN RESUMED AT 
NEXT VERB, PERIOD, OR INFORMATION IN THE 
A MARGIN. 

See subscripts. 

***** CANNOT BE USED AS AN ARGUMENT FOR THE 

CORRESPONDING OPTION. 

See the CORRESPONDING option of the ADD, SUB- 
TRACT, and MOVE verbs. 
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***** CANNOT HAVE MORE THAN 49 QUALIFIERS. 
EXTRA ONES DELETED. 
Self-explanatory. 

CANNOT USE VARIABLE LENGTH ITEMS FOR COM- 
PARISON. NOTHING DONE. 

See IF conditional statements in the PROCEDURE 

DIVISION. 

CARD SEQUENCE ERROR IN COLUMNS 1-6. CONDITION 
IGNORED. 

The card sequence has been checked and this error mes- 
sage results. There is no effect on compilation. 

CARD UNIT NOT ALLOWED AS SECONDARY UNIT AS- 

nT/~!-\.TT-iT-\ r-r*s-\ ttitt tt» ***** n-nn/\Mr\ a Tf\.T ttattht a rrrnxT 
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MENT IGNORED. 

See the FILE-CONTROL paragraph in the INPUT- 
OUTPUT section of the ENVIRONMENT DIVISION. 

CAUTION, GROUP ITEM ***** TESTED. 

A group item was an operand of an EXAMINE or IF 
class-test-type statement. This is a warning message. 

CAUTION, GROUP LEVEL MOVE FROM ***** TO *****. 
See the MOVE CORRESPONDING verb. 

CAUTION, MOVE FROM ***** TO ***** CAUSES TRUN- 

This message indicates that either the size or number of 
decimal places of the items did not match. There is a 
possibility that information will be lost. 

CAUTION, MOVE FROM ***** TO ***** CAUSES TRUN- 
CATION EXCEPT IN CASES OF SYNCHRONIZATION. 

This message indicates that there might be a loss of 
significant data. 

CHARACTER LOGIC MOVE INVOLVING AN ITEM 
LONGER THAN 32767 CHARACTERS. NOTHING GEN- 
ERATED. 

This message indicates a compiler limitation has been 

reached. 

CHECKPOINTS DESIGNATED TO BE WRITTEN ON FILE 
***** BUT FILE IS NOT LABELED OUTPUT. CHECK- 
POINTS WILL BE WRITTEN ON STANDARD CHECK- 
POINT UNIT INSTEAD. 

iiiij liicoocij^c iiiun_cii.es uicu uneuKpumis caimoi oe 
written on an input file or an unlabeled output file. 

CLOSE REEL FOR ***** IS ILLEGAL SINCE FILE IS AS- 
SIGNED TO A CARD OR SYSTEM UNIT. REEL OPTION 
IGNORED. 

Self-explanatory. 

COBOL COMPILER DOES NOT OBEY THE USE OF XR4 
XR5, OR XR6 ON $IBCBC CARD. XR3 IS ASSUMED. 

Index register 3 and 7 are the only index register specifi- 
cations accepted. See the CONFIGURATION SECTION 
of the ENVIRONMENT DIVISION. 

COBOL WORD ***** WAS NOT FOUND WHERE RE- 
QUIRED IN THIS STATEMENT. STATEMENT DELETED. 
This message indicates a language violation. See the rules 
regarding the use of the particular verb used. 

COBOL WORD 'SECTION' XfTSSTVfJ REHTYYTYG nv 

***** SECTION ASSUMED BY COMPILER. 

See "Organization of Source Program" and the EN- 
VIRONMENT DIVISION. 

COBOL WORDS 'ASSIGN TO' OMITTED IN SELECT EN- 
TRY *****. ASSUMED UNIT ASSIGNMENTS IS T TAPE- 
UNIT. 

See the FILE-CONTROL paragraph in the INPUT- 
OUTPUT SECTION of the ENVIRONMENT DIVI- 
SION. 



COBOL WORDS 'TO PROCEED TO' NOT FOUND WHERE 
REQUIRED IN ALTER STATEMENT. STATEMENT DE- 

See the ALTER verb. 

'COLLATE-COMMERCIAL' SHOULD NOT APPEAR IN EN- 
VIRONMENT DIVISION. COLLATING SEQUENCE AS- 
SUMED COMMERCIAL UNLESS 'BINSEQ' APPEARS ON 
SIBCBC CARD. 

This message indicates obsolete wording. 

COMMA ILLEGALLY TO RIGHT OF POINT IN PICTURE 
OF REPORT ITEM *****. + + + + + IS ASSUMED PIC- 
TURE. 

See the PICTURE clause of the data-item description. 

COMPILER ***** COUNT CONTROL CONVENTION ***** 
FILE ***** 

See the file description entry in the DATA DIVISION. 

COMPILER ***** COUNT CONTROL CONVENTION ***** 
FILE ***** UNLESS ***** IS ASSIGNED TO A CARD 
UNIT AT OBJECT-TIME. 

See the file description entry in the DATA DIVISION. 

COMPILER ALLOWS ONLY 20 CONSECUTIVE IMPLIED 
BOOLEAN OPERATORS. CONDITIONAL EXPRESSION 
DELETED SINCE MAXIMUM EXCEEDED. 
ureaK tue expression into smaner parts. 

COMPILER ASSUMES FILE(S) ASSOCIATED WITH FD 
ENTRY ***** HAS LABEL RECORD SINCE VALUE OF 
LABEL GIVEN. 

See the LABEL and VALUE clauses of the file descrip- 
tion entry. 

COMPILER BASE LOCATOR CAPACITY EXCEEDED. TRY 
SUBDIVIDING INTO SMALLER PROGRAMS FOR SEP- 
ARATE COMPILATION WITH COMBINATION AT OB- 
JECT TIME. 

This message indicates a compiler limitation has been 

reached. 

COMPILER FORCED TO ASSUME ***** IS A GROUP ITEM 
DUE TO ERROR IN SUBSEQUENT LEVEL NUMBER. 
See level-numbers in the DATA DIVISION. 

COMPILER IGNORES ILLEGAL CLAUSES IN DESCRIP- 
TION OF LEVEL 88 CONDITION ***** (ONLY VALUE 
IS ALLOWED). 

See condition-name in the DATA DIVISION. 

COMPILER TABLE CAPACITY EXCEEDED. TRY SUB- 
DIVIDING INTO SMALLER PROGRAMS FOR SEPARATE 
COMPILATION WITH COMBINATION AT OBJECT TIME. 

This message indicates that a compiler limitation has 
been exceeded. Suggested action is included in the 
message. 

COMPILER THWARTED IN SEARCHING DATA STRUC- 
TURE bOH UKOUP(S) CONTAINING ARRAY ***** PROB- 
ABLY DUE TO TOO MANY SUBSCRIPTS GIVEN. OBJECT 
PROGRAM USES FIRST ELEMENT OF THE ARRAY. 

See subscripts. 

CONDITIONAL EXPRESSION TEST CAPACITY EX- 
CEEDED. REWRITE AS TWO OR MORE SEPARATE 
EXPRESSIONS WITH A MAXIMUM OF 18 OPERATORS. 
ILLEGAL SENTENCE STRUCTURE. NOTHING DONE. 

This message indicates that a compiler limitation has 

been reached. 

CONDITIONAL VARIABLE ***** IMPROPERLY DE- 
SCRIBED AS A REPORT, SCIENTIFIC DECIMAL, OR 
FLOATING POINT ITEM. X IS ASSUMED PICTURE. 
See conditional variables. 

CONFLICTING 'USE' OPTIONS FOR FILE ***** OVER- 
RIDDEN BY 'USE' STATEMENTS S) FOR ***** FILES. 
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This message indicates that conflicting USE procedures 
have occurred. See the USE verb. 

CONTINUATION CHARACTER MUST NOT BE USED 
WITH AN OCCUPIED A MARGIN. CONTINUATION 
CHARACTER IGNORED. 

Continued items must not begin before B margin. See 

"Reference Format." 

CONTROL CARD ENCOUNTERED PRECEDING $CBEND 
CARD. END OF COBOL TEXT ASSUMED. 

It is assumed that the $CBEND card is missing. 

COPY OPTION NOT IMPLEMENTED. FD ENTRY 
IGNORED. 

Enter the information in detail. 

CORRESPONDING FIELDS OF ***** AND ***** OVER- 
LAP 

See the MOVE CORRESPONDING verb. 

CROSS-REFERENCE NAME TOO LONG. FIRST 6 CHAR- 
ACTERS USED. 

A cross-reference name is limited to 6 characters. See 

the ENTER verb. 

DATA DIVISION-HEADER NOT FOLLOWED BY SEC- 
TION-NAME. SCAN RESUMED AT NEXT DATA DE- 
SCRIPTION ENTRY, SECTION, OR DIVISION. 

See the "Organization of Source Program" and DATA 

DIVISION. 

DATA ITEM ***** INVALID AS AN ARGUMENT IN 
'EXAMINE' STATEMENT OR CLASS TEST. STATEMENT 
DELETED. 

See the EXAMINE verb. 

DATA ITEM ***** IS UNDER INFLUENCE OF INCON- 
SISTENT USAGE AND CLASS CLAUSES. DETERMINING 
HIERARCHY IS PICTURE, USAGE, CLASS. 

See the data-item description in the DATA DIVISION. 

DATA ITEM ***** WITH REDEFINES CLAUSE NOT 
PRECEDED BY AN ELEMENTARY ITEM. REDEFINES 
IGNORED. 

The redefining item must follow the redefined item with 
no intervening entries. See the REDEFINES clause of 
the data-item description. 

DATA-NAME, NOT ******, EXPECTED AS ARGUMENT 
IN THIS STATEMENT. STATEMENT DELETED. 

See the rules regarding the use of the particular verb 

referred to in this message. 

DATA-NAME ***** REQUIRING CONVERSION, EDITING, 
OR DEFINITION MAY NOT APPEAR IN AN ACCEPT 
STATEMENT. NOTHING DONE. 
See the ACCEPT verb. 

DATA RECORDS CLAUSE COMMITTED IN FD ENTRY 
*****. CONDITION IGNORED. 

See the DATA RECORDS clause of the file description 

entry. 

DECK NAME IN 'CALL' STATEMENT MUST BE EN- 
CLOSED IN QUOTES. STATEMENT DELETED. 

This message indicates a language rule violation. See 

the ENTER verb. 

DECK NAME IS MISSING ON $IBCBC CARD. CONDI- 
TION IGNORED 

Self-explanatory. 

'DECLARATIVES' MUST BE AT BEGINNING OF PROCE- 
DURE DIVISION. STATEMENT DELETED. 

This message indicates a language requirement. See "Or- 
ganization of Source Program." 



***** DEFINED IN MORE THAN ONE OUTPUT FILE. 
INPUT/OUTPUT STATEMENT IGNORED. 
The record name used must be unique. 

***** DESCRIPTION ENTRY ENCOUNTERED. BEGIN- 
NING OF ***** SECTION ASSUMED BY COMPILER. 

See "Organization of Source Program" and the DATA 

DIVISION. 

DISCREPANCY BETWEEN LEVELS OF ***** AND THE 
REDEFINED ITEM. DISCREPANCY IGNORED AT THIS 
POINT OF ANALYSIS. 

The redefining item should match the redefined item. In 
this case, the level numbers do not match. This is a 
warning level message. See the REDEFINES clause of 
the data-item description. 

DIVISION NAME SHOULD BE FOLLOWED BY THE 
WORD DIVISION AND A PERIOD. CONDITION IG- 
NORED. 

Self-explanatory. 

DIVISIONS MUST BE IN ORDER AND NOT DUPLI- 
CATED. COMPILER SKIPS TO NEXT DIVISION. 
See "Organization of Source Program." 

$ IS A LEGAL CHARACTER ONLY IN THE PICTURE 
CLAUSE. $ DELETED. 
Self-explanatory. 

DOUBLE ASTERISKS (INDICATING EXPONENTIATION) 
SHOULD NOT BE SEPARATED BY SPACE(S). SPACE(S) 
IGNORED. 

See formulas in the COMPUTE statement in the PRO- 
CEDURE DIVISION. 

DOWNSCALE GENERATED WHICH LOSES ALL SIGNI- 
FICANT DIGITS. 

This message indicates that data has been lost due to 

downscaling. 

ELEMENTARY LEVEL CLAUSES IN DESCRIPTION OF 
GROUP ITEM ***** IGNORED (I.E., VALUE, SIGNED, 
POINT, SYNCHRONIZED, EDITING, OR PICTURE.) 

Certain clauses apply only to elementary items. See the 

discussion of the particular clause. 

END OF COBOL MESSAGES. 
Self-explanatory. 

ENVIRONMENT ***** NOT FOLLOWED BY ***** SCAN 
RESUMED AT NEXT PARAGRAPH, SECTION, OR DIVI- 
SION. 

See "Organization of Source Program" and the EN- 
VIRONMENT DIVISION. 

ENVIRONMENT PARAGRAPH-NAME ENCOUNTERED. 
BEGINNING OF ***** SECTION ASSUMED BY COM- 
PILER. 

See the ENVIRONMENT DIVISION. 

ERRONEOUS PARENTHESIZATION IGNORED. TRANS- 
LATION CONTINUES ARBITRARILY. 

The number of left parentheses should equal the number 

of right parentheses. 

ERROR IN OCCURS . . . DEPENDING ON CLAUSE IN DE- 
SCRIPTION OF *****. COMPILER ASSUMES OCCURS EX- 
ACTLY 100 TIMES, IGNORING QUANTITY ITEM. 

See the OCCURS clause in the data-item description 

entry. 

ERRORS IN OCCURS ... DEPENDING ON CLAUSE IN 
DESCRIPTION OF *****, COMPILER IGNORES 'INTEGER 
- 1 TO' SPECIFICATION. 

See the OCCURS clause in the COBOL manual. 

ERROR MESSAGE NOT YET IN FILE. 

This message should never appear. If it does, a systems 
engineer should be called to initiate an error report. 
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ERROR NUMBER ** DUMMY ** . 

This message precedes a debugging printout. 

EXCESSIVE BLOCK SIZE SPECIFIED FOR FILE *****. 
FILE IS SET UNBLOCKED. 

See the BLOCK CONTAINS clause of the file description 

entry. 

EXTRANEOUS 'ELSE' FOUND. IF IN 'AT END' OR 'ON 
SIZE ERROR' CLAUSE, 'ELSE' TREATED AS A PERIOD, 
IN OTHER CASES IT IS TREATED AS A COMMA. 

This message indicates a language violation. See the rales 
regarding the particular verb for which ELSE is an 
option. The statement must be rewritten to eliminate 
the extraneous ELSE. 

FD ENTRY ***** NOT TERMINATED BY A PERIOD. 
CONDITION IGNORED. 
Self-explanatory. 

FIGURATIVE CONSTANT OR NON-NUMERIC LITERAL 
MUST FOLLOW 'ALL'. ALL ZERO ASSUMED IF COBOL 
WORD NEXT. 

See figurative constants. 

FILE ***** ASSIGNED TO *****, BUT FILE IS NOT *****. 
***** USAGE ASSUMED. 

File usage is contradictory to system unit usage. 

FILE ***** ASSIGNED TO CARD UNIT HAS RECORD 
CONTAINING MORE THAN 72 CHARACTERS. MAXIMUM 
RECORD SIZE PROCESSED IS 72 CHARACTERS. 

Card column limitation has been exceeded. There are 
only 72 columns available. The first 72 characters will be 
processed. 

FILE ***** ASSIGNED TO SYSOU1, BUT RECORDING 
MODE GIVEN AS BINARY. RECORDING MODE 
CHANGED TO BCD. 

This message indicates a system requirement; SYSOU1 
must be BCD. 

FILE ***** ASSOCIATED WITH REDUNDANT 'USE' 

STATEMENT. FIRST ONE RETAINED. 

This message indicates that a redundant USE statement 
has been encountered. See the USE verb. 

FILE ***** HAS NO ASSOCIATED FD ENTRY. ARBI- 
TRARY SPECIFICATIONS ASSUMED. 
See the file description entry. 

FILE ***** HAS NO RECORDS. INPUT/OUTPUT STATE- 
MENT IGNORED. 

See the DATA RECORDS clause of the file description 

entry. 

FILE ***** IS ASSIGNED TO A CARD OR SYSTEM UNIT. 

OPTIONS SPECIFIED IN CLOSE STATEMENT ARE 

IGNORED. 

This message indicates that certain system conventions 
(as indicated) take priority over COBOL options. 

FILE ***** IS ASSIGNED TO ***** AND FILE RECORD- 
ING MODE IS BINARY. UNIT NOT PERMITTED TO BE 
CARD AT OBJECT-TIME. 

This message indicates that system units SYSIN1, 
SYSOU1, and SYSPP1, should not be specified as card 
units at execution time. This is a system restriction. 

FILE ***** IS ASSIGNED TO ***** AND MAXIMUM REC- 
ORD SIZE EXCEEDS 72 CHARACTERS. UNIT NOT PER- 
MITTED TO BE CARD AT OBJECT-TIME. 

This message indicates that system units SYSIN1, 
SYSOU1, and SYSPP1, should not be specified as card 
units at execution time. This is a system restriction. 

***** FILE ***** IS ASSIGNED TO *****. UNIT NOT PER- 
MITTED TO BE CARD AT OBJECT-TIME. 

This message indicates that system units SYSIN1, 



SYSOU1, and SYSPP1 should not be specified as card 
units at execution time. This is a system restriction. 

***** FILE ***** N oT PERMITTED AS ARGUMENT IN 
'USE' OPTION ***** STATEMENT. 
See the USE verb. 

FILE ***** RETENTION-PERIOD SPECIFICATION IG- 
NORED SINCE ALLOWED ONLY FOR OUTPUT FILE. 

See the VALUE clause of the file description entry in 

the COBOL manual. 

FILE ***** SPECIFIED AS ***** INPUT ***** OUTPUT. 
***** USAGE ASSUMED. 

This message indicates that the rules governing the use 

,. , „,■„,-, it 1 • 1 . 1 O il- - TTCT7 1 1~ 

n i *~he UbJi. verD nave oeen violated, oee me uoij vciu. 



'FILLER' NOT PERMITTED AS FILE-NAME. FD ENTRY 
IGNORED. 

Self-explanatory. 

FIRST REPETITION OF SUBSCRIPTING ERROR. SUB- 
SEQUENTLY, MESSAGES REFERRING TO SUBSCRIPTS 
APPEAR ONLY ONCE CORRESPONDING TO THE FIRST 
APPEARANCE OF EACH UNIQUE SUBSCRIPT DATA- 
NAME OR EXPRESSION. 

No further messages will be generated for this error. 

r.T/%imr>in Tirvrvirr ttxtttatt'TJTT'T mX7 /""/"M^TX 717 TJ TrMP T TT 
JfLUAlllNVj JTWllN 1 UlMJILhrijUVV \junviiiiiinvj J-u. x - 

ERAL. ZERO USED. 

This message indicates the exponent became less than 
the minimum exponent which is 2" 128 (approximately 

io- 3S ). 

FLOATING POINT OVERFLOW IN CONVERTING LIT- 
ERAL. MAXIMUM VALUE USED. 

This message indicates the exponent became greater 
than the maximum exponent which is 2 +127 (approxi- 
mately 10 +as ). 

***** FORCED TO LEVEL NUMBER OF 01. 

Every data organization must have the highest order 
„o. t v~ r\i u,,„t c„„ i„ v „i „„ m V' '" *h° DATA DI- 

VISION. 

***** ***** TTPQVT ***** ***** -pQ ***** *****^ 
***** ***** 

See the MOVE verb. 

'FROM' MAY ONLY BE FOLLOWED BY IBJOB STAND- 
ARD MNEMONIC NAME 'SYSIN1'. SYSIN1 ASSUMED. 
See the rules for the ACCEPT verb. 

GROUP ITEM ***** USED AS A SUBSCRIPT. OBJECT 
PROGRAM USES SUBSCRIPT VALUE OF 1. 
See subscripts. 

***** HAS AN ILLEGAL LEVEL NUMBER. ASSUMED 
LEVEL NUMBER IS 49. 

Valid level-numbers are 01 through 49, 77, and 88. 

If any other number is specified, 49 will be assumed. 

See level-numbers. 

***** HAS AN ILLEGAL PICTURE. ***** IS ASSUMED 
PICTURE. 

See the PICTURE clause of the data-item description. 

***** HAS NO FILE DESCRIPTION. INPUT/OUTPUT 

STATEMENT IGNORED. 

See the verb being used. Also check for proper wording 
of the file description entry and the FILE -CONTROL 
paragraph. 

***** HAS NOT APPEARED IN A SELECT ENTRY IN 
ENVIRONMENT DIVISION. FD ENTRY IGNORED. 
Self-explanatory. 

***** HAS NOT BEEN DEFINED IN A SELECT ENTRY 
AND IS IGNORED. 
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See the FILE-CONTROL paragraph of the INPUT- 
OUTPUT SECTION in the ENVIRONMENT DI- 
VISION. 

***** HAS VALUE CLAUSE TOGETHER ILLEGALLY 
WITH OCCURS OR REDEFINES. VALUE ACCEPTED 
IF OCCURS - APPLIED TO FIRST ELEMENT. 

The OCCURS clause or the REDEFINES clause has 
been used illegally with the VALUE clause. See the 
three clauses in the data-item description entry. 

HYPHENATED FORM OF ***** DESIGNATION 
PREFERRED. 

See the CONFIGURATION SECTION of the 

ENVIRONMENT DIVISION. 

I-O-CONTROL OPTIONS FOR ***** IGNORED SINCE 
ALLOWED ONLY FOR BINARY FILES. 

This message reflects a system IOCS requirement. 

I-O-CONTROL PARAGRAPH NOT FOLLOWING FILE- 
CONTROL PARAGRAPH IGNORED. 

See "Organization of Source Program" and the EN- 
VIRONMENT DIVISION. 

ILLEGAL ***** UNIT ASSIGNED TO FILE *****. ***** 
See the FILE-CONTROL paragraph in the INPUT- 
OUTPUT SECTION of the ENVIRONMENT DIVI- 
SION. 

ILLEGAL ARGUMENT IN 'ON' STATEMENT. STATE- 
MENT DELETED. 

Refer to "Debugging Package" in the COBOL manual. 

ILLEGAL ARITHMETIC PHRASE, ENDING WITH AN 
OPERATOR OTHER THAN RIGHT PARENTHESIS. 
PHRASE DELETED. 

See formulas in the COMPUTE statement of the 

PROCEDURE DIVISION. 

ILLEGAL CHARACTER IN COLUMN 7. SPACE IS 
ASSUMED. 

A hyphen or a blank are the only characters allowed 

in column 7. See "Reference Format." 

ILLEGAL CHARACTER IN LITERAL. CHARACTER 
IGNORED. 

This message indicates one of the basic rules has been 
violated. See literals. 

ILLEGAL CHARACTER ON CARD DELETED. 
Self-explanatory. 

ILLEGAL CLAUSE(S) DESCRIBING ***** IGNORED 
LENGTH 1, VALUE OF R. M. ASSIGNED BY COMPILER 
ONLY SYNCHRONIZATION, IF ANY, RETAINED. 

Consult the specific format for the record mark (PIC- 
TURE J). 

ILLEGAL CLAUSE(S) IN DESCRIPTION OF FLOATING 

POINT ITEM ***** IGNORED. 

See the discussion on the specific format for floating-point 
items in the USAGE clause of the data-item description 
entry. 

ILLEGAL CLAUSE(S) IN DESCRIPTION OF SCIENTIFIC 

DECIMAL ITEM ***** IGNORED. 

See the discussion on the specific format for scientific 
decimal items in the PICTURE clause of the data-item 
description entry. 

ILLEGAL CONDITIONAL EXPRESSION IN AT END OR 
ON SIZE ERROR CLAUSE. 

This message has been generated because of a COBOL 
language restriction, but this 7090/7094 compiler accepts 
the statement. See the description of the AT END clause 
of the READ verb or of the ON SIZE ERROR clause 
relating to the ADD, SUBTRACT, MULTIPLY, or DI- 
VIDE verbs. 



ILLEGAL CONDITIONAL EXPRESSION IN TEXT. EX- 
PRESSION IGNORED. 

See conditional statements in the PROCEDURE DIVI- 
SION. 

ILLEGAL CONTROL SECTION NAME FOR DEBUG RE- 
QUEST. NAME IGNORED. 

Refer to "Debugging Package" in the COBOL manual. 

ILLEGAL DESIGNATION OF SIGN CONVENTION IN PIC- 
TURE OF REPORT ITEM *****. + + + + + + + IS AS- 
SUMED. 

See the report form of the PICTURE clause of the data- 
item description entry. 

ILLEGAL FORM OF VALUE FOR ***** ***** VALUE 
IGNORED. 

Self-explanatory. 

ILLEGAL INSERTION POINT SPECIFICATION FOR DE- 
BUG REQUEST. REQUEST WILL NOT BE EXECUTED. 

Refer to "Debugging Package" in the COBOL manual. 

ILLEGAL MIXTURE OF DIGIT POSITION CHARACTERS 
(9 Z *) AFTER POINT IN PICTURE OF REPORT ITEM 
*****. + + + + + + + IS ASSUMED PICTURE. 

See the report form of the PICTURE clause of the data- 
item description entry. 

ILLEGAL MIXTURE OF ORDER OF DIGIT POSITION 
CHARACTERS IN PICTURE OF REPORT ITEM *****. 
+++++++ IS ASSUMED PICTURE. 

See the report form of the PICTURE clause of the data- 
item description entry. 

ILLEGAL PICTURE OF SCIENTIFIC DECIMAL ITEM 
*****. +99999999E + 99 IS ASSUMED PICTURE. 

See the scientific decimal form of the PICTURE clause 

of the data-item description entry. 

ILLEGAL PICTURE (OR NEITHER PICTURE NOR LEGAL 
SIZE GIVEN) FOR ***** DECIMAL ITEM *****. 999999 
IS ASSUMED PICTURE. 

The size must be specified by either the SIZE or the 

PICTURE clause. 

ILLEGAL POINT OR SIGNED CLAUSE IN DESCRIPTION 

OF NON-REPORT DISPLAY ITEM *****. 

See the data-item description entry in the DATA DIVI- 
SION. 

ILLEGAL REDEFINITION IGNORED FOR FILE RECORD 

(01 LEVEL) NAMED *****. 

The REDEFINES clause cannot be used with logical 
records (01 level) associated with the same file. See the 
REDEFINES clause of the data-item description entry. 

ILLEGAL SENTENCE STRUCTURE. NOTHING DONE. 
See "Punctuation." 

ILLEGAL SUBSCRIPT STRUCTURE. SCAN RESUMED AT 
NEXT VERB, PERIOD, OR INFORMATION IN THE A 
MARGIN. 

See subscripts. 

ILLEGAL USAGE OR CLASS CLAUSE (OR BLANK WHEN 
ZERO) IN DESCRIPTION OF ALPHANUMERIC ITEM 
*****. CLAUSE IGNORED IN FAVOR OF PICTURE. 

This warning message indicates a violation of a language 

rule. 

ILLEGAL USAGE OR CLASS CLAUSE(S) IGNORED IN 
FAVOR OF PICTURE OF REPORT ITEM *****. 

The PICTURE clause overrides contradictory USAGE 

and CLASS clauses. 

ILLEGAL USE OF COMMA IN PICTURE OF REPORT 
ITEM *****. + + + + + + + is ASSUMED PICTURE. 
Self-explanatory. 
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ILLEGAL USE OF $ IN PICTURE OF REPORT ITEM 
***** + + + + + + + IS ASSUMED PICTURE. 
See replacement characters under the PICTURE clause 
of the data-item description entry. 

ILLEGAL USE OF UNALTERABLE 'GO TO' STATEMENT. 
'GO TO' STATEMENT DELETED. 

See the GO TO and ALTER verbs. 

ILLEGAL USE OF V OR POINT IN PICTURE OF REPORT 
ITEM *****. + + + + + + + IS ASSUMED PICTURE. 

See the report form of the PICTURE clause of the data- 
item description entry. 

IMPROPER CHARACTER INTERRUPTS STRING OF + 
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+ + + + + + + IS ASSUMED PICTURE. 

See the floating +, — , or $ in the report form of the 
PICTURE clause of the data-item description entry. 

IMPROPER LABEL CLAUSE IGNORED. COMPILER AS- 
SUMES LABEL RECORD(S) OMITTED UNLESS VALUE 
CLAUSE PRESENT. 

See the LABEL clause of the file description entry. 

IMPROPER RECORDING CLAUSE IGNORED. BCD, HIGH 

DENSITY ASSUMED. 

See the RECORDING MODE clause of the file de- 
scription entry. 

***** IN THE ENVIRONMENT DIVISION MUST NOT BE 
REPEATED. SCAN RESUMED AT NEXT PARAGRAPH, 
SECTION, OR DIVISION. 

See "Organization of Source Program" and the EN- 
VIRONMENT DIVISION. 

INCOMPLETE STATEMENT DELETED 

This message indicates invalid sentence structure. Con- 
sult the rules regarding the particular verb in the 
COBOL manual. 

INELIGIBLE DATA-NAME ***** IN RECEIVE OR PRO- 
VIDE STATEMENT. SCAN RESUMED AT NEXT VERB, 
PERIOD, OR INFORMATION IN THE A-MARGIN. 
See the "ENTER" verb. 

INELIGIBLE DATA-NAME CANNOT BE USED AS AN 
ARGUMENT FOR THE CORRESPONDING OPTION. 

See the CORRESPONDING clause under the MOVE 

verb. 

'INPUT' OR 'OUTPUT MUST FOLLOW VERB IN AN 
'OPEN' STATEMENT. STATEMENT DELETED. 

The OPEN statement requires that either INPUT or 
OUTPUT be specified. See the OPEN verb. 

INPUT/OUTPUT STATEMENT IGNORED. 

See the PROCEDURE DIVISION discussion on the 
associated verb. Often associated with errors concerning 
SELECT or FD entries. 

INTEGER MUST NOT EXCEED 32767. INTEGER 1 
ASSUMED. 

This message indicates that core storage capacity has 

been exceeded. 

^INCONSISTENT FILE 

AND SERIAL 
(PERMANENT CLOSE 
v UNABLE TO STASH 
I READ OUT SEQUENCE 
UTILITY READ 
\ UTILITY EOF 
Possible causes: 

1. "short" or faulty utility tapes 

2. oversize program 

3. machine error 
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INVALID LITERAL USED IN EXAMINE STATEMENT. 
S elf -explanatory . 

***** IS A NAM e DEFINITION AND MUST NOT BE 
QUALIFIED. DEFINITION FORCED. 

This message refers to a data-name, condition-name, 
or procedure-name that was not properly defined; see 
the statement being used. 

***** IS A TYPE OF ELEMENTARY DATA ITEM THAT 
MAY NOT BE USED AS A SUBSCRIPT. OBJECT PRO- 
GRAM USES SUBSCRIPT VALUE OF 1. 

See subscripts. 

***** IS A TYPE OF ELEMENTARY DATA ITEM THAT 
MAY NOT BE USED IN 'RETURN'. SATEMENT 
DELETED. 

See the ENTER verb. 

***** IS AN OUT-OF-RANGE REFERENCE. 

Refer to "Debugging Package" in the COBOL manual. 

***** IS AN UNRECOGNIZABLE ITEM ON CARD. COM- 
PILER SKIPS TO NEXT DIVISION. 

The remainder of division is skipped. Check for spelling 

error. 

***** IS GREATER THAN *****. FIRST VALUE USED 
IN DETERMINING MAXIMUM ***** SIZE. 
See "FD." 

***** IS IMPROPERLY QUALIFIED. DEFINITION 
FORCED. 

See subscripts. 

***** IS IMPROPERLY QUALIFIED. NAME IS NOT UNI- 
QUE. DEFINITION FORCED. 

This message refers to a data-name, condition-name, or 
procedure-name that was not properly defined; see quali- 
fication of names. 

***** IS NOT *****. INPUT/OUTPUT STATEMENT 

IGNORED. 

The READ verb requires a filename; the WRITE verb 
requires a record name. See the rules regarding the par- 
ticular verb. 

***** i S NO t A FILE NAME. FD ENTRY IGNORED. 

There is no legitimate SELECT entry in FILE-CON- 
nivyi-i jjcuagiapju. oee tiie imn v lni^iNivicrN i i>»ivioici\ 
and the FILE SECTION of the DATA DIVISION. 

***** IS NOT A file-NAME. I-O-CONTROL CLAUSE 

IGNORED. 

A spelling error may have occurred in the file-name and 
no match can be found. The I-O-CONTROL paragraph 
in the INPUT-OUTPUT SECTION of the ENVIRON- 
MENT DIVISION is ignored. 

***** IS NOT A LEGAL CONDITION-NAME. REMAINDER 

v/F SWITCH-NAME ENTRY IGNORED. 

See the SPECIAL-NAMES paragraph in the CON- 
FIGURATION SECTION of the ENVIRONMENT 
DIVISION. 

***** IS NOT A LEGAL FILE-NAME. SELECT ENTRY 

IGNORED. 

A language rule has been violated. See the FILE-CON- 
TROL paragraph in the INPUT-OUTPUT SECTION 
of the ENVIRONMENT DIVISION. 

***** IS NO t A LEGAL MNEMONIC-NAME. REMAINDER 

OF SWITCH-NAME ENTRY IGNORED. 

See the SPECIAL-NAMES paragraph in the CON- 
FIGURATION SECTION of the ENVIRONMENT 
DIVISION. 

***** IS N0T A LITERAL. CLAUSE IGNORED. 

See the VALUE clause of the data-item description entry. 
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***** IS NOT A NUMERIC LITERAL AND IS IGNORED. 

See the VALUE clause of the file description entry. 

***** IS NOT A PROCEDURE NAME. TRANSFER BYPASS- 
ING THIS STATEMENT INSERTED. 

Incorrect reference. See the structure of the PRO- 
CEDURE DIVISION. 

***** IS NOT DEFINED. DEFINITION FORCED UNLESS 

A QUALIFIER. 

This message refers to a data-name, condition-name, or 
procedure-name that was not properly defined; see 
qualification. 

***** IS STRUCTURALLY INCORRECT AT THIS POINT. 

I-O-CONTROL CLAUSE IGNORED. 

A section head has been omitted. See "Organization of 
Source Program" and the ENVIRONMENT DIVISION. 

***** IS STRUCTURALLY INCORRECT AT THIS POINT. 

REMAINDER OF SWITCH-NAME ENTRY IGNORED. 

See the SPECIAL-NAMES paragraph in the CON- 
FIGURATION SECTION of the ENVIRONMENT 
DIVISION. 

***** IS STRUCTURALLY INCORRECT AT THIS POINT. 

SCAN RESUMED AT BEGINNING OF NEXT RERUN 

CLAUSE, PERIOD, OR PROPER INFORMATION IN THE 

A MARGIN. 

See I-O-CONTROL paragraph of the INPUT-OUTPUT 
SECTION of the ENVIRONMENT DIVISION. 

***** IS STRUCTURALLY INCORRECT AT THIS POINT. 
SCAN RESUMED AT BEGINNING OF NEXT SELECT EN- 
TRY, PERIOD, OR PROPER INFORMATION IN THE A 
MARGIN. 

See the FILE-CONTROL paragraph in the INPUT- 
OUTPUT SECTION of the ENVIRONMENT DIVI- 
SION. 

***** IS STRUCTURALLY INCORRECT AT THIS POINT. 
SCAN RESUMED AT BEGINNING OF NEXT SWITCH- 
NAME ENTRY, PERIOD, OR PROPER INFORMATION IN 
THE A MARGIN. 

See "Organization of the Source Program" and the EN- 
VIRONMENT DIVISION. 

***** IS STRUCTURALLY INCORRECT AT THIS POINT. 
SCAN RESUMED AT NEXT VERB, PERIOD, OR INFOR- 
MATION IN THE A MARGIN. 

This message indicates that a language rule has been 
violated. See the PROCEDURE DIVISION information 
for the particular verb used. 

***** IS UNIDENTIFIABLE. CLAUSE IGNORED. 
See the DATA DIVISION. 

***** IS UNIDENTIFIABLE. REMAINDER OF CLAUSE 

IGNORED. 

See the FILE SECTION of the DATA DIVISION. This 
wording may also concern the PROCEDURE DIVISION; 
see message below. 

***** IS UNIDENTIFIABLE. REMAINDER OF CLAUSE 

IGNORED. 

Check spelling. Also study the rules of the particular verb 
used in this clause. This wording may also concern the 
FILE SECTION of the DATA DIVISION; see message 
above. 

***** IS UNRECOGNIZABLE IN PROBABLE MULTIPLE 
REEL OPTION. MULTIPLE REELS ASSUMED. 

This message indicates a probable spelling error. 

***** IS UNRECOGNIZABLE. SCAN RESUMED AT NEXT 
DATA DESCRIPTION ENTRY, SECTION, OR DIVISION. 
See the DATA DIVISION. 



***** IS UNRECOGNIZABLE. SCAN RESUMED AT NEXT 
PARAGRAPH, SECTION, OR DIVISION. 
See the PROCEDURE DIVISION. 

ITEM ***** HAS NO SPECIFIED LENGTH. CONDITION 
IGNORED. 

Length of a data-item must be specified. See the 
PICTURE and SIZE clauses of the data-item descrip- 
tion entry. 

JUSTIFIED CLAUSE IN DESCRIPTION OF ***** 
IGNORED. THIS FEATURE NOT IMPLEMENTED. 

The JUSTIFIED clause is not a feature of 7090/7094 

COBOL. 

LABEL CLAUSE OMITTED IN FD ENTRY *****. COM- 
PILER ASSUMES LABEL RECORD(S) OMITTED. 

See the LABEL clause of the file description entry. 

LENGTH OF NON-NUMERIC LITERAL EXCEEDS 
LENGTH SPECIFIED BY SIZE OR PICTURE CLAUSE 
FOR *****. LOW ORDER TRUNCATION DONE. 

The alphanumeric constant contained within the VALUE 
clause should not be greater in size than the item. 
When it is greater, the low order portion is truncated. 

LENGTH OF ***** NOT BOTH CONSTANT AND LESS 
THAN 73 CHARACTERS. NOTHING DONE. 
See the ACCEPT verb. 

LENGTH (***** CHARACTERS) OF REDEFINING DATA 
FIELD HEADED BY DATA-NAME ***** IS GREATER 
THAN LENGTH (***** CHARACTERS) OF DATA FIELD 
BEING REDEFINED. DANGEROUS CONDITION 
IGNORED. 

See the REDEFINES clause of the data-item descrip- 
tion entry. 

LEVEL FD SHOULD APPEAR IN THE A MARGIN. A 
MARGIN ASSUMED. 

This message indicates a violation of a language rule. 

See "Reference Format." 

LEVEL OF ***** CONFLICTS WITH THE PRECEDING 
LEVEL NUMBER CONDITION IGNORED. 

See level-numbers in the data-item description entry. 

LEVEL 77 ITEM ***** MAY NOT HAVE OCCURS. 

See independent items ( level number 77 ) in the WORK- 
ING-STORAGE and CONSTANT SECTION. 

LEVEL 77 ITEM ***** APPEARS IN FILE SECTION. IN- 
VALID DATA' ORGANIZATION RESULTS. 

Level 77 items are allowed only in the WORKING- 
STORAGE and CONSTANT SECTION. 

LEVEL 88 CONDITION ***** LACKS MANDATORY 
VALUE CLAUSE. 

Condition-names (level-number 88) must have a 

VALUE clause. See condition-names. 

LEVEL 88 CONDITION ***** APPEARS ILLEGALLY IN 
CONSTANT SECTION. 

Condition-names (level-number 88) have no meaning 
in the CONSTANT SECTION. See condition-names. 

LEVEL 88 CONDITION ***** NOT PRECEDED BY VALID 
ELEMENTARY ITEM. 

See condition-names. 

LIMIT (15 BITS) OF SIZE FIELD IN DICTIONARY 
NECESSITATES TREATING OPERATION LENGTH OF 
***** AS MODULO 32768. 

This message indicates a compiler limitation has been 

reached. 

LITERAL FOLLOWING ALL IS LIMITED TO ONE CHAR- 
ACTER. THE FIRST LITERAL CHARACTER IS USED. 
See figurative constants. 
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***** LITERAL IS TOO LONG. FIRST ***** CHAR- 
ACTERS WILL BE USED. 

See the VALUE clause of the file description entry, 

MACHINE OR COMPILER ERROR. COMPILATION IS 
INCOMPLETE. 

( 1 ) This message may indicate a machine error. Notify 
a customer engineer. (2) This message may indicate a 
compiler error. Consult a system engineer concerning 
the APAR procedure. 

MAXIMUM NUMBER ***** OF DIFFERENT NAMES IN 
A SOURCE PROGRAM EXCEEDED. COMPILATION 
TERMINATED. 

This message indicates that a compiler limitation has 
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programs. 

MAXIMUM RECORD SIZE (***** COMPUTER WORDS) 
EXCEEDS SPECIFIED BLOCK SIZE (***** COMPUTER 
WORDS) OF FILE *****. FILE IS SET UNBLOCKED. 

This message indicates that the blocksize specified was 
not large enough. See the BLOCK CONTAINS clause 
of the file description entry. 

MAXIMUM RECORD SIZE (***** COMPUTER WORDS) 
SPECIFIED IN FD ENTRY ASSOCIATED WITH FILE 
***** IS NOT EOUAL TO SIZE OF MAXIMUM RECORD 
(***** COMPUTER WORDS). FD RECORD CLAUSE 
IGNORED. 

This message indicates that there is an inconsistency 
between the record size specified in the file description 
entry and the record size given in the descriptions of 
the record. See RECORD CONTAINS and SIZE clauses 
in the FILE SECTION. 

MESSAGE CAPACITY EXCEEDED. 

This message indicates a compiler limitation. No more 
error messages can be generated. At least one further 
error has not been recorded. 

MISUSE OF PERIOD. SIGN. OR E IN LITERAL. ILLEGAL 

CHARACTER(S) IGNORED. 

This message indicates one of the mentioned rules has 
been violated. See literals in the COBOL manual. 

MIXED CONTIGUOUS INSERTION-CHARACTERS IN 
PICTURE OF REPORT ITEM *****. + + + + + + + IS AS- 
SUMED PICTURE. 

See insertion characters under the PICTURE clause of 

the data-item description entry. 

MNEMONIC ***** NOT UNIQUE, CONDITION IGNORED. 
See the SPECIAL-NAMES paragraph in the CON- 
FIGURATION SECTION of the ENVIRONMENT 
DIVISION. 

MOVE FROM A FIGURATIVE CONSTANT TO A VARIA- 
BLE LENGTH GROUP ITEM NOT ALLOWED. 
See the MOVE verb. 

MOVE FROM A FIGURATIVE CONSTANT TO AN ITEM 
LONGER THAN 32767 CHARACTERS NOT ALLOWED. 

This message indicates a compiler limitation has been 
reached. Suggest dividing data-item into smaller parts. 

MULTIPLE ***** CLAUSES IN ***** DATA DESCRIP- 
TION. FIRST ONE RETAINED. 

This message indicates an extraneous clause has ap- 
peared. Only the first- clause is retained. 

MULTIPLE ***** CLAUSES IN FD ENTRY *****. FIRST 
ONE RETAINED. 

See the file description entry. 

MULTIPLE CONTIGUOUS INSERTION-CHARACTERS IN 
PICTURE OF REPORT ITEM ***** CHANGED TO A SIN- 
GLE CHARACTER. 



This message indicates a compiler convention. See the 
report form of the PICTURE clause in the data-item de- 
scription entry. 

MULTIPLE REEL OPTION FOR FILE ***** OMITTED 

WHERE REQUIRED BUT IS ASSUMED. 

MULTIPLE REEL must be specified if a file is on two 
or more reels of magnetic tape. See the FILE-CONTROL 
paragraph of the INPUT-OUTPUT SECTION in the 
ENVIRONMENT DIVISION. 

NEITHER PICTURE NOR SIZE CLAUSE GIVEN FOR 
NON-REPORT DISPLAY ITEM *****. X IS ASSUMED PIC- 
TURE. 

Self-explanatory. 

NEITHER PICTURE NOR SIZE CLAUSE GIVEN FOR RE- 
PORT ITEM *****. ******* IS ASSUMED PICTURE. 
See the data-item description entry. 

NESTED REDEFINES ILLEGAL. REDEFINES CLAUSE 

IGNORED FOR *****. 

Redefining is not allowed at a subordinate level to an- 
other REDEFINES. No more than one REDEFINES in 
one organization is permitted. 

NO DIGIT POSITIONS IN PICTURE OF REPORT ITEM 

*****. + + + + + + IS ASSUMED PICTURE. 

§ ee tVj 8 report form of the PICTURE clause in the data- 
item description entry. 

NO ERRORS WERE DETECTED BY THE COMPILER 

Self-explanatory. 

NO PARAGRAPH NAME FOUND PRECEDING 'EXIT 
STATEMENT. CONDITION IGNORED. 

EXIT must always be a one-word paragraph. See the 

discussion of the EXIT verb. 

NO RECORD DESCRIPTION ENTRIES FOLLOW FD EN- 
TBY ***** 

See "Organization of Source Program" and the DATA 

DIVISION. 

NON-ALPHABETIC LITERAL GIVEN FOR ALPHABETIC 
ITEM *****. CONDITION IGNORED. 

The value given for an alphabetic item may not contain 

non-alphabetic characters. 

NON-NUMERIC LITERAL CONTINUATION MUST BEGIN 
WITH A QUOTE, QUOTE ASSUMED PRECEDING FIRST 
NON-SPACE CHARACTER. 

See "Reference Format." 

NON-NUMERIC LITERAL LONGER THAN 120 CHARAC- 
TERS OR NAME LONGER THAN 30 CHARACTERS TRUN- 
CATED. 

This message indicates a language restriction. See 
literals. 

NON-NUMERIC LITERAL VALUE OF NUMERIC ITEM 

***** IGNORED. 

Numeric items may have only numeric values. See the 
VALUE clause in the DATA DIVISION. 

***** NOT A LABEL-DATA-NAME. REMAINDER OF 
VALUE CLAUSE IGNORED. 

See the VALUE clause of the file description entry. 

NOT IN 'DECLARATIVES' MODE. STATEMENT DE- 
LETED. 

The USE verb may be used only in the declarative sec- 
tion. See the USE verb. 

NOTE . . . FILE-NAME CHANGED FOR INTERNAL PUR- 
POSES TO *****. 

Internal limitations make change of file name mandatory. 

No information is lost. 
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NUMBER OF DIGITS IN FIELD OF LITERAL EXCEEDS 

LIMIT OF 18. 18 DIGITS USED. 

A numeric literal may not contain more than 18 charac- 
ters. See the rules for literals. 

NUMBER OF FILES NAMED IN FILE-CONTROL EX- 
CEEDS MAXIMUM OF 63. COMPILATION TERMINATED. 
This message indicates that a compiler limitation has 
been reached. This is a D-level message causing com- 
pilation to stop. A dump will also result. It is suggested 
that the job be broken into smaller jobs. 

NUMBER OF OCCURRENCES OF ***** IS ILLEGAL. 
COxMPILER ASSUMES OCCURS EXACTLY 100 TIMES. 

See the OCCURS clause of the data-item description 

entry. 

NUMBER OF OCCURRENCES OF ITEM ***** DEPENDS 
ON A FOLLOWING ITEM IN THE SAME DATA GROUP. 
'DEPENDING ON' CLAUSE IGNORED. 

The description of the item that determines the number 
of repetitions cannot follow the item with the OCCURS 
DEPENDING ON clause. See the OCCURS clause of 
the data-item description entry. 

OBJECT-COMPUTER DESIGNATION OVERRIDDEN BY 

***** OPTION ON $IBCBC CARD. 

This message indicates that the number of index regis- 
ters specified on the $IBCBC card does not agree with 
the number of index registers designated by the object- 
computer. 

OCCURS CLAUSE IGNORED FOR CONDITIONAL VARI- 
ABLE *****. 

See conditional variables. 

OCCURS CLAUSE NOT PERMITTED FOR HIGHEST 

LEVEL DATA ITEM *****. 

This message indicates a language limitation. An 
OCCURS clause may not be used at 01 level. 

***** OF FILE ***** ASSIG NED TO ***** NOT PER- 
MITTED. 

This message indicates a system function error. Blocking 

is not permitted on system units. 

***** QF GROUP ITEM ***** IGNORED DUE TO CON- 
FLICT WITH A HIGHER ORDER GROUP. 

Self-explanatory. 

ONLY FILE-NAMES MAY BE USED AS ARGUMENTS IN 
'OPEN' OR 'CLOSE' STATEMENTS. STATEMENT DE- 
LETED. 

See OPEN and CLOSE statements in the PROCEDURE 

DIVISION of the COBOL manual. 

OPERAND TABLE OVERFLOW TRANSLATING EXPRES- 
SION. STATEMENT DELETED. 

The statement is too large. Rearrange the statement in 

smaller parts. 

OPERATION IGNORED BECAUSE ***** HAS IMPROPER 
DATA FORMAT. 

See the rules regarding the particular verb. 

OPERATION IGNORED BECAUSE ILLEGAL USE OF 
FIGURATIVE CONSTANT. 

See figurative constants. 

***** ORDER TRUNCATION OCCURS IN GENERATION 
OF INITIAL VALUE FOR *****. 

See VALUE clause of the data-item description entry. 

***** PARAGRAPH APPEARS ILLEGALLY IN ***** SEC- 
TION. SCAN RESUMED AT NEXT PARAGRAPH, SECTION, 
OR DIVISION. 

See "Organization of Source Program" and ENVIRON- 
MENT DIVISION. 



PERFORM STATEMENT STRUCTURALLY INCORRECT. 
STATEMENT DELETED. 

See the PERFORM verb. 

PERMANENT READ ERROR DURING PROCEDURE IN- 
STRUCTION GENERATION PHASE. COMPILATION IS 
SUSPECT. 

This message indicates a bad utility tape. Do not trust 

compilation. Suggest re-compilation. 

PICTURE OF ALPHANUMERIC ITEM ***** CONTAINS 

A MIXTURE OF A'S AND 9'S - TREATED AS ALL X'S. 

This message indicates a language rule violation. 

PICTURE OF REPORT ITEM ***** HAS ILLEGAL USE 
OF SCALING CHARACTER P. + + + + + + + IS ASSUMED 
PICTURE. 

See the PICTURE clause of the data-item description 

entry. 

PICTURE OF REPORT ITEM ***** HAS SCALING CHAR- 
ACTER P EMBEDDED ILLEGALLY BETWEEN NUMERIC 
CHARACTER POSITIONS. + + + + + + + IS ASSUMED 
PICTURE. 

See the PICTURE clause of the data-item description 

entry. 

PICTURE OF REPORT ITEM ***** IS ILLEGAL. 

+ + + + + + + IS ASSUMED PICTURE. 

See the report form of the PICTURE clause in the data- 
item description entry. 

PREVIOUS DATA DESCRIPTION NOT TERMINATED BY 
A PERIOD. PERIOD ASSUMED AND PROCESSING OF 
***** BEGUN. 

Self-explanatory. 

PRIMARY AND SECONDARY UNITS ASSIGNED TO FILE 
***** CONFLICT. SECONDARY UNIT ASSIGNMENT 
IGNORED. 

Self-explanatory. 

PROCEDURE STATEMENT TO ***** FILE ***** NOT 

GIVEN. 

Every file named in a SELECT statement in the FILE- 
CONTROL paragraph of the ENVIRONMENT DIVI- 
SION must be opened and closed in the PROCEDURE 
DIVISION. See the verbs OPEN and CLOSE. 

QUANTITY ITEM ***** SHOULD NOT BE USED WITH 
'REPLACING' OPTION IN 'EXAMINE' STATEMENT. CON- 
DITION IGNORED. 

See the EXAMINE verb. 

RECORD ***** APPEARS IN RECORD DESCRIPTION 
ENTRY BUT WAS NOT LISTED IN THE FD DATA 
RECORD(S) CLAUSE. CONDITION IGNORED AND REC- 
ORD DESCRIPTION RETAINED. 

See the DATA RECORDS clause of the file description 

entry. 

RECORD HEADED BY DATA ITEM ***** EXCEEDS 32767 
WORDS. LENGTH MODULO 32768 USED. 

This message indicates a compiler limitation has been 

reached. 

RECORD ***** LISTED IN THE FD DATA RECORD(S) 
CLAUSE DOES NOT APPEAR IN A RECORD DESCRIP- 
TION ENTRY. CONDITION IGNORED. 

See the DATA RECORDS clause of the file description 

entry. 

REDEFINES DESCRIBING ***** NOT FOLLOWED BY A 
PREVIOUSLY DEFINED DATA-NAME. CLAUSE 
IGNORED. 

See the REDEFINES clause of the data-item description 

entry. 
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REDUNDANCY ON SYSTEM INPUT UNIT. CONDITION 
IGNORED. 

One card image may have been lost. Suggest recom- 
pilation. 

REDUNDANT FD ENTRY ***** IGNORED. 
Self-explanatory. 

REDUNDANT FD ENTRY ***** IGNORED. ONLY ONE 
FD ENTRY MAY DESCRIBE A SET OF RENAMED 
SELECT ENTRIES. 

See the description of RENAMING clause of the 

SELECT entry. 

REDUNDANT I-O-CONTROL SPECIFICATION. 

SEQUENCE-CHECK, CHECK-SUM, or RERUN has 
been specified more than one time for a given file in the 
I-O-CONTROL, paragraph of the ENVIRONMENT 
DIVISION. For example, the following two cards in the 
same program will cause check-sum to be specified for 
FILE-NAME-1 twice: 

APPLY CHECK-SUM ON FILE-NAME-1. 
APPLY CHECK-SUM ON ALL FILES. 
The card whose number is given with the message con- 
tains the SELECT entry for the file involved. 

REDUNDANT SELECT ENTRY ***** IGNORED. 

A file-name has been selected more than once in the 
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DIVISION. 

REDUNDANT SWITCH-NAME ENTRY FOR KEY ***** 

IGNORED. 

See the SPECIAL-NAMES paragraph of the ENVIRON- 
MENT DIVISION. 

REDUNDANT 'USE' STATEMENT. Statement Deleted 

This message indicates that a redundant USE statement 
has been encountered. See the USE verb. 

'RENAMING MAY ONLY BE FOLLOWED BY A FILE- 
NAME, REMAINDER OF SELECT ENTRY IGNORED. 
ASSUMED UNIT ASSIGNMENT IS '1 TAPE-UNIT. 

If the RENAMING option is used in the FILE-CON- 
TROL paragraph of the ENVIRONMENT DIVISION, 
it must be followed by a file-name. 

SECTION-HEADER ***** SECTION NOT FOLLOWED BY 
***** DESCRIPTION ENTRY. SCAN RESUMED AT NEXT 
***** DESCRIPTION ENTRY, SECTION, OR DIVISION. 
See "Organization of Source Program." 

SECTIONS IN THE DATA DIVISION MUST ***** SCAN 
RESUMED AT NEXT SECTION, OR DIVISION. 
See "Organization of Source Program." 

SENTENCE LENGTH EXCEEDS COMPILER CAPACITY. 
SUGGEST SUBDIVIDING SENTENCE INTO SMALLER 
COMPONENTS. 

Self-explanatory. 

SEQUENCE-CHECK MUST BE SPECIFIED WHEN 
CHECK-SUM IS SPECIFIED, SEQUENCE-CHECK AS- 
SUMED. 

This message reflects a system (IOCS) requirement. 

729-MODEL NO. ***** ASSIGNED TO FILE *****, NOT 
ACCEPTABLE TO LOADER, CHANGED BY COMPILER 

TQ ***** 

This message indicates a system restriction. Certain 729 
Magnetic Tape Units cannot be used. 

***** SHOULD BE FOLLOWED BY A SPACE. SPACE IS 
ASSUMED. 

See "Punctuation." 

***** SHOULD NOT BE FOLLOWED BY A SPACE. CON- 
DITION IGNORED. 

See "Punctuation." 



***** SHOULD NOT BE IN THE A MARGIN. B MARGIN 
ASSUMED. 

C „ "13 „(„,.„„ — , tP ,j. " 
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SIZE OF ***** GIVEN AS 0. COMPILER ASSUMES SIZE 
IS 6. 

Zero is an illegal size. 

SIZE, POINT, SIGNED, OR EDITING CLAUSES IGNORED 

IN FAVOR OF PICTURE IN *****. 

This message indicates that some information has been 
duplicated. In this case, the PICTURE clause informa- 
tion is contrary to similar information specified in an- 
other clause. The PICTURE is correct. 

SOURCE-COMPUTER IS IMPROPERLY SPECIFIED. IBM- 

7090 ASSUMED. 

The hyphen must be specified in "IBM-7090" in the 
CONFIGURATION SECTION of the ENVIRONMENT 
DIVISION. 

***** SPECIFICATION ***** REMAINDER OF VALUE 
CLAUSE IGNORED. 

See the VALUE clause of the file description entry. 

***** SPECIFICATION IN ***** CLAUSE NOT AN UN- 
SIGNED INTEGER. CLAUSE IGNORED. 
See the DATA DIVISION. 

***** SPECIFICATION IN ***** CLAUSE NOT AN UN- 
SIGNED INTEGER. REMAINDER OF CLAUSE RE- 
TAINED. 

See the DATA DIVISION. 

STATEMENT CONTAINS TOO FEW RIGHT PAREN- 
THESES. COMPENSATING PARENTHESES ADDED AT 
END OF STATEMENT. 

The number of right parentheses must equal the number 

of left parentheses. 

STATEMENT CONTAINS TOO MANY RIGHT PAREN- 
THESES. EXTRA PARENTHESES IGNORED. 

The number of right parentheses must equal the number 

of left parentheses. 

STATEMENT REQUIRES A DATA-NAME, LITERAL, OR 
FIGURATIVE CONSTANT, NOT *****, AS AN ARGUMENT, 
STATEMENT DELETED. 

See the rules regarding the use of the particular verb 
referred to in this message. 

STATEMENT REQUIRES A PROCEDURE NAME, NOT 
*****, AS AN ARGUMENT. STATEMENT DELETED. 

See the rules regarding the use of the particular verb 

referred to in this message. 

SUBORGANIZATION OF ITEM ***** WITH OCCURS 
CLAUSE CONTAINS A VALUE CLAUSE. VALUE GIVEN 
TO FIRST ELEMENT ONLY. 

A VALUE clause cannot appear in a description sub- 
ordinate to one containing an OCCURS clause. See the 
VALUE and OCCURS clauses of the data-item descrip- 
tion entry. 

SUBSCRIPT COUNT EXCEEDS 3. SCAN RESUMED AT 
NEXT VERB, PERIOD, OR INFORMATION IN THE A 
MARGIN. 

Only three levels of subscripting are allowed. See "Sub- 
scripts." 

SUBSCRIPT INTEGER MUST NOT EXCEED 32767. IN- 
TEGER 1 ASSUMED. 

This message indicates that a compiler limitation has 

been exceeded. 
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SUBSCRIPT MISSING AFTER LEFT PARENTHESIS. SCAN 
RESUMED AT NEXT VERB, PERIOD, OR INFORMATION 
IN THE A MARGIN. 

Information has been omitted. 

SYNCHRONIZED ITEM ***** HAS REDEFINES CLAUSE. 

STORAGE ASSIGNMENT MIGHT NOT BEGIN WITH THE 

FIRST CHARACTER POSITION OF THE REDEFINED 

AREA. CONDITION IGNORED. 

This message indicates the characteristics of the RE- 
DEFINES clause take priority. 

SYSIDR ACCOUNTING ROUTINE ERROR. 

Contact your systems engineer whenever this message 
occurs. 

T2 WORD-************ L(TSX) -***** L(SKEL) - 

Consult your systems engineer concerning APAR proce- 
dure whenever this message occurs. It is always accom- 
panied by the MACHINE OR COMPILER ERROR 
message. 

TERMINATION OF LITERAL FORCED AT END OF CARD. 
This message indicates that either a quote mark or a 
continuation mark has been omitted. See literals. 

TOO FEW OPERANDS IN ADD STATEMENT. STATE- 
MENT DELETED. 

A minimum of two operands is allowed in an ADD 

statement. 

TOO FEW SUBSCRIPTS GIVEN FOR ***** COMPILER 
ASSUMES MISSING LEFTMOST SUBSCRIPTS TO BE 1. 
See subscripting. 

TRANSFER BYPASSED BECAUSE ***** IS NOT A STATE- 
MENT OR SECTION NAME. 
Self-explanatory. 

21 PERMANENT READ REDUNDANCIES ON SYSTEM 
INPUT UNIT. COMPILATION TERMINATED. 

This message indicates 21 card read errors. Compilation 

is terminated and a dump is taken. 

UNIDENTIFIABLE WORD ***** IN DATA DESCRIPTION. 
WORD OR CLAUSE IGNORED. 

This message indicates a program error. See the DATA 

DIVISION. 

'UPON' MAY ONLY BE FOLLOWED BY IBJOB STANDARD 
MNEMONIC-NAME 'SYSOU1'. SYSOU1 ASSUMED. 

SYSOU1 is the only unit permitted for DISPLAY state- 
ments. 

UPSCALE MAY CAUSE HIGH ORDER TRUNCATION 

FOR STORE INTO *****. 

High-order truncation may occur because of decimal 
point alignment in a receiving area that is too small. An 
error will probably result from this operation. 

'USE' NOT PRECEDED BY SECTION-NAME. 

See the rules regarding the USE verb in the declarative 
section of the PROCEDURE DIVISION. 

***** USED AS A SUBSCRIPT HAS AN ALPHANUMERIC 
PICTURE, BUT VALUES MUST BE RESTRICTED TO 
INTEGERS. 

The data-item referred to contains non-numeric charac- 
ters, possibly blanks. This message is a warning only, 
but the results obtained during execution are likely to 
be wrong. See "Subscripts." 

***** USED AS A SUBSCRIPT HAS AN ALPHABETIC PIC- 
TURE. INVALID SUBSCRIPT. OBJECT PROGRAM USES 
SUBSCRIPT VALUE OF 1. 
See "Subscripts." 



***** USED AS SUBSCRIPT IS A SIGNED EXTERNAL 
DECIMAL ITEM. NEGATIVE VALUES CAUSE ERRORS. 
Subscripts must have positive integer values. See "Sub- 
scripts." 

***** USED AS A SUBSCRIPT IS IN BCD. OBJECT-TIME 
CONVERSION AND/OR UNPACKING IS REQUIRED FOR 
SUBSCRIPTS NOT COMPUTATIONAL, SYNCHRONIZED 
RIGHT. 

In most cases computational, synchronized right items are 

more efficient as subscripts. 

***** USED AS A SUBSCRIPT. IS INVALID DUE TO NON- 
ZERO SCALING. OBJECT PROGRAM USES SUBSCRIPT 
VALUE OF 1. 

Subscripts must be positive integers. See "Subscripts." 

***** USED AS A SUBSCRIPT. IS NOT SYNCHRONIZED 
RIGHT. OBJECT-TIME UNPACKING IS REQUIRED. 

In most cases synchronized right items are more efficient 

as subscripts. 

*****, USED TO CONTROL A GO TO, HAS ILLEGAL FOR- 
MAT. GO TO STATEMENT IGNORED. 

See the GO TO DEPENDING ON statement in the 

PROCEDURE DIVISION. 

*****, USED TO CONTROL A GO TO, IS NOT AN IN- 
TEGER. INTEGER PART USED. 

See the GO TO DEPENDING ON statement in the 

PROCEDURE DIVISION. 

'USING' MUST BE FOLLOWED BY THE NAME OF A 
FIXED-LOCATION DATA-ITEM. STATEMENT DELETED. 

See the description of the CALL form of the ENTER 

verb. 

VALUE CLAUSE OF ITEM ***** IGNORED SINCE IT IS 
EITHER REDEFINED, PRECEDED BY A VARIABLE 
LENGTH ITEM, OR IS IN THE FILE SECTION. 

This message indicates that certain clauses are contra- 
dictory. See the VALUE clause of data-item description. 

VALUE CLAUSE OMITTED IN FD ENTRY *****. LEGAL 
BUT UNUSUAL. 

See the VALUE clause of the file description entry. 

WARNING. LISTING OF THIS NAME HAS BEEN TER- 
MINATED. PROGRAM IS NOT AFFECTED. 

The REF has been used. Because the number of items 
cross-referenced exceeds compiler limitations, the REF 
list may be incomplete. 

***** WITH REDEFINES CLAUSE NOT IMMEDIATELY 
PRECEDED BY THE REDEFINED AREA. REDEFINES 
IGNORED. 

The redefining item must follow the redefined item with 
no intervening entries. See the REDEFINES clause of 
the data-item description entry. 

'WITHOUT' MUST BE FOLLOWED BY COBOL WORDS 
'COUNT CONTROL' IN RECORDING CLAUSE. NOTHING 
DONE. 

See the RECORDING MODE clause of the file descrip- 
tion entry. 

WORDING 'EVERY BEGINNING OF REEL' PREFERRED 

IN RERUN CLAUSE AND IS ASSUMED. 

This message indicates obsolete wording. See the I-O- 
CONTROL paragraph of the ENVIRONMENT DIVI- 
SION. 

Note: If a compilation is terminated and a dump 
taken with no error message being printed, a systems 
engineer should be notified. 
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If the Assembler encounters a card in error, it will be 
flagged with a number. At the end of the assembly 
listing, the number is printed with an error message 
explaining the error, and a severity indication is given. 
The severity indication is a numerical code: 

LEVEL MEANING 

1 Trivial error. Does not affect assembly or execution. 

2 Definite error. Assembly supplies probable interpreta- 
tion. Execution is not permitted. 

3 Serious error. Assembly supplies guess interpretation. 
Execution is not permitted. 

4 Unrecoverable error. No interpretation attempted. As- 
sembly continues. Execution is not permitted. 

5 Useless to continue assembly. Return to Processor Moni- 
tor after printing of all errors detected. 

In a normal assembly, messages are printed just after 
the assembly listing. All messages for a given card are 
printed together, and the card groups are printed in 
ascending sequence. Correlation with the listing is ac- 
complished by printing the card number assigned by 
the assembly, in the left margin of the listing, for each 
card that requires a message. Messages printed when 
the nolist option is in effect will have no listing for 
visual correlation. However, since the card numbers are 
assigned sequentially for every card processed ( includ- 
ing duplicate sequences and macro-generated cards) 
correlation can be made, though perhaps with difficulty. 

The following alphabetical list contains the messages 
generated by the Assembler. The symbol "******" in- 
dicates a location in the error message where the 
Compiler inserts a variable word. Where a variable 
word is the first in the message, the message is listed 
alphabetically on the next nonvariable word. 

Note: One of the Assembler error messages, 
"location field format error" has a special applica- 
tion when the original source deck is coded in the 
corol language. If any other map message occurs in 
connection with a cobol source deck error, the pro- 
grammer should call a systems engineer. 

7094 INSTRUCTION ONLY. 

Level 1. Assembled as -NOP-. 

ADDRESS NOT ALLOWED. 

Level 1. Zero used for address. 

ADDRESS NOT EXPECTED. 
Level 1. Address used. 

ADDRESS REQUIRED. 

Level 1. Zero used for address. 

BAD ADJECTIVE CODE USED FOR -OPD- OR -OPVFD-. 
Level 4. 



BIT COUNT TOO LARGE FOR -VFD- OR -OPVFD- SUB- 
FIELD. 

Level 4. 864 is the maximum allowed. 

BOOLEAN CONSTANT TRUNCATED TO SIX DIGITS. 
Level 2. 

BOOLEAN FIELD MUST BE CONSTANT, 
Level 2. 

-CALL- OPERATION WITH BLANK VARIABLE FIELD 
IGNORED. 

Level 3. 

CONTROL DICTIONARY ENTRY FOR ****** ELIMI- 
NATED. IMPROPER REFERENCE. 

Level 4. References to symbols which are absolute or 
which are defined by EQUs, BOOLs, and SETs are 
invalid. 

CONTROL DICTIONARY NOT CORRECTLY PROCESSED. 
ASSEMBLER OF MACHINE ERROR. 
Level 4. Bad text encountered. 

COUNT FIELD ON -BCI- CARD CANNOT EXCEED SIX 
DIGITS. 

Level 4. A count of 1 is used. 

COUNT FIELD ON -BCI- CARD IMPROPERLY TERMI- 
NATED. COUNT OF ONE USED. 
Level 4. 

COUNT FIELD ON -VFD- CANNOT EXCEED SIX DIGITS. 
Level 4. First six digits used. 

DEBUGGING FORMAT ERROR. 

Level 1. Analysis of variable field is completed. 

DEBUGGING TABLE OVERFLOW DEBUGGING 
IGNORED. 

Level 1. Table length is approximately 6,200 locations. 

DECIMAL CONSTANT TOO LARGE. 

Level 2. Truncated to 15 bits. 

DECIMAL POINT CAN OCCUR ONLY IN PRINCIPAL 
PART OF LITERAL OR CONSTANT. 
Level 2. 

DECREMENT MUST BE CONSTANT AND CANNOT EX- 
CEED ****** BITS. 
Level 2, 

DECREMENT NOT ALLOWED. 

Level 1. Zero used for decrement. 

DECREMENT NOT EXPECTED. 

Level 1. Low order 6 bits used. 

DECREMENT REQUIRED. 

Level 1. Zero used for decrement. 

DUBIOUS USE OF * ASSUMED TO BE LOCATION 
COUNTER. 

Level 4. 

DUBIOUS USE OF ****** ON -FILE- CARD. 

Level 1. Indicates 'HYPER' option missing. The name 
shown where ****** appears in the message will be 
processed. 

-DUP- CARD PUSH DOWN TABLE OVERFLOW. 
Level 5. Limit of nested DUP's is 32. 
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-END- CARD SHOULD FOLLOW. 

Level 4. An -END- card is simulated. 

END OF FILE WHILE PROCESSING -DUP- CARD. 
Level 4. An -END- card is simulated. 

END OF FILE WHILE PROCESSING SOURCE INPUT. 
Level 4. An -END- card is simulated. 

-END- SHOULD NOT OCCUR IN MACRO DEFINITION. 
Level 5. 

-END- SHOULD NOT OCCUR IN RANGE OF A -DUP-. 
Level 4. An END card is processed. 

-ETC- CARD SHOULD FOLLOW. 
Levels 1 and 2. 

EXTERNAL LABEL FOR FILE TOO LONG. FIRST 18 
CHARACTERS USED. 
Level 3. 

EXTERNAL NAME ****** SUPPLIED FOR THIS CDICT 
ENTRY. 

Level 1. 

-FILE- CARD MUST HAVE SYMBOL IN LOCATION 
FIELD. 

Level 4. Card ignored. 

FLOATING POINT OVERFLOW IN CONVERTING LIT- 
ERAL OR CONSTANT. 

Level 2. Value set to highest possible (all binary l's). 

FLOATING POINT UNDERFLOW IN CONVERTING LIT- 
ERAL OR CONSTANT. 

Level 2. Value set to zero. 

FORMAT ERROR FOLLOWING = SIGN ON -FILE- CARD. 
Level 3. 

FORMAT ERROR IN FIRST SUBFIELD. 
Levels 2 and 3. Card ignored. 

I, D OR E OCCURRED MORE THAN ONCE FOR -SAVE- 
OPN. 

Level 1. Redundant field ignored. 

ILLEGAL BCD CHARACTER TREATED AS IF BLANK. 
Level 4. 

ILLEGAL COUNT FIELD ON -BCI- CARD. 
Level 4. Count of 1 used. 

ILLEGAL INTERNAL CONDITION. ASSEMBLER OR MA- 
CHINE ERROR. 
Level 5. 

ILLEGAL OPERAND IN THE VARIABLE FIELD. 
Level 4. 

ILLEGAL QUALIFICATION USAGE ON THIS CARD. 
Levels 1 and 3. 

ILLEGAL SCAN CONDITION. ASSEMBLER OR MACHINE 
ERROR. 

Level 5." 

ILLEGAL SUBFIELD IGNORED FOR -SAVE- OPN. 
Level 3. 

ILLEGAL TERMINATOR FOR DECIMAL CONSTANT. 
Level 4. 

ILLECAL USE OF -ETC- CARD. 
Level 1. Card ignored. 

ILLEGAL VARIABLE FIELD CONDITION AT START OF 
-ETC- CARD. 

Level 4. Ignore this and remaining -ETC- cards. 



IMPROPER PUNCTUATION FOLLOWING HOLLERITH 
LITERAL. 

Level 4. Punctuation ignored. 

INCORRECT DUPLICATE SEQUENCE. 

Level 5. The range of a -DUP- that occurs within the 
range of another -DUP- must be fixed before the outer 
-DUP- is encountered. See IBM 7090/7094 IBSYS Oper- 
ating System: Macro Assembly Program (MAP) Langu- 
age, Form C28-6392, for further details. 

INCORRECT FORM OF VARIABLE FIELD ON -CONTRL- 
OR -FILE- CARD. 

Level 3. Card ignored. 

INCORRECT FORM OF VARIABLE FIELD ON -ORGCRS- 
CARD. 

Level 1. Card treated as if variable field were blank. 

INDEX SPECIFIED MORE THAN ONCE FOR -SAVE- OPN. 
Level 1. Redundancies ignored. 

INDIRECT' ADDRESS NOT ALLOWED ON THIS IN- 
STRUCTION. 
Level 1. 

INTERNAL DICTIONARY FULL. ASSEMBLE PROGRAM 
IN SMALLER PARTS. 
Level 5. 

INTERNAL DICTIONARY OVERFLOW WHILE PROCESS- 
ING CONTROL DICTIONARY. 

Level 4. Assemble program in smaller parts. 

INTERNAL TEXT_ SYNCHRONIZATION FAILURE. AS- 
SEMBLER Ori MAc;HINh, i^KKUK. 
Level 4. 

INVALID INDEX SPECIFIED FOR -SAVE- OPN. 
Level 1. Guess used for index value. 

-IRP- IGNORED. VARIABLE FIELD ERROR. 
Level 1. 

LOCATION FIELD FORMAT ERROR. 

Illegal characters ignored. If this message refers to the 
initial SAVE card of an assembly following a COBOL 
compilation, however, a numeric deck name has been 
used on the $IBCBC card for the deck. If there is no 
reference to the deck name in the program, this error 
should not be harmful. 

LOCATION FIELD REQUIRED ON THIS CARD. 
Levels 2 and 4. Card ignored. 

MACRO CALL HAS TOO MANY PARAMETERS. 
Level 1. Excess parameters ignored. 

MACRO DEFINITION CANNOT HAVE MORE THAN 63 
PARAMETERS. 

Level 4. Excess parameters ignored. 

MACRO DEFINITION CARD WITHOUT NAME IGNORED. 
Level 1. 

MACRO DEFINITION NESTING ERROR. 

Level 1. Missing -ENDM- cards simulated. 

MACRO DEFINITION TERMINATED BY -ENDM- CARD 
WITH BLANK VARIABLE FIELD. 

Level 1. Macro definition terminated. 

MACRO DEFINITION TERMINATED BY -ENDM- CARD 
WITH WRONG NAME. 

Level 1. Macro definition terminated. 

MACRO GENERATION SYNCHRONIZATION FAILURE. 
ASSEMBLER OR MACHINE ERROR. 

Level 4. Expansion of current macro terminated. 
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MACRO PARAMETER EXPANSION TABLE OVERFLOW. 
Level 5. Results from substitution being too long and/or 
too many parameters in macro call. 

MACRO PARAMETER PUSH DOWN TABLE OVERFLOW. 
Level 5. Results from substitution being too long and/or 
too many parameters in macro call. 

MACRO SKELETON TABLE OVERFLOW. NO MORE 
DEFINITIONS ACCEPTED. 

Level 4. Too many macro definitions. Try PURGE. 

MISUSE OF E OR B IN LITERAL OR CONSTANT. 
Level 2. Invalid characters ignored. 

MISUSE OF PARENTHESES IN MACRvj DErliNiTION. 
Level 3. 

MISUSE OF PARENTHESES ON -CALL- OPERATION. 

Level 3. 

MIXED BOOLEAN EXPRESSION. LEFT BOOL USED. 
Level 1. 

MORE THAN ONE -BEGIN- FOR THIS LOCATION COUN- 
TER. ALL BUT FIRST IGNORED. 
Level 4. 

MORE THAN ONE DECIMAL POINT FOR LITERAL OR 
CONSTANT. ALL BUT FIRST IGNORED. 

Level 2. 

MORE THAN ONE SIGN FOR EXPONENTIAL OR BINARY- 
PLACE PART OF LITERAL OR CONSTANT. 

Level 2. 

MORE THAN ONE SIGN FOR PRINCIPAL PART OF 
LITERAL OR CONSTANT. 
Level 2. 

****** IS AN IMPROPERLY QUALIFIED NAME. 

Level 1. Frequently caused by multiple definitions of 
names. 

****** IS AN IMPROPER QUALIFIER. 
Level 1. 

****** IS AN UNDEFINED SYMBOL. 
Level 1. 

NAME SUPPLIED FOR -SAVE- OPN. 
Level 1. 

NAME TABLE FULL. ASSEMBLE PROGRAM IN SMALLER 
PARTS. 

Level 5. Approximately 3,500 programmer symbols may 

be used. 

NON-NUMERIC CHARACTER IN 'ID' FIELD OF -CALL-. 
Level 1. TD' field ignored and line number used. 

NO PREVIOUS LOCATION COUNTER BLANK COUNTER 
USED. 

Level 2. 

NUMERIC FIELD CONTAINS NON-NUMERIC CHARAC- 
TER. FIELD IGNORED. 
Level 1. 

OCTAL CONSTANT CANNOT EXCEED 12 DIGITS. 

Level 2. Field truncated to 12 digits. 

OCTAL CONSTANT CONTAINS NON-OCTAL CHAR- 
ACTER. 

Level 2. 

ONE OR MORE QUALIFICATION SECTIONS NOT 
CLOSED. 

Level 4. 

ONLY FIRST -LDIR- EFFECTIVE, 
a-ievel x. 



ONLY FIRST -LORG- EFFECTIVE. 
Level 1. 

OPERATION CODE NOT IN DICTIONARY. 
Level 1. Card ignored. 

OPERATION CODE NOT IN DICTIONARY. PURGED. 

Level 1. Card ignored. 

OPERATION CODE REDEFINED. 
Level 1. New definition used. 

OPERATION FIELD FORMAT ERROR. 
Level 1. 

PRINCIPAL, EXPONENTIAL OR BINARY-PLACE PART 
OF LITERAL OR CONSTANT TOO LONG. FIELD TRUN- 
CATED TO MAXIMUM DIGIT SIZE. 

Level 2. 

PERMANENT READ ERROR ON SECOND PASS TEXT 
INPUT. 

Level 4. 

PRINCIPAL PSEUDO-OPERATION CANNOT BE DE- 
FINED. 

Levels 2 and 4. Usually due to circular definition. 

PSEUDO-OPERATION DICTIONARY FULL. ASSEMBLE 
PROGRAM IN SMALLER PARTS. 
Level 5. 

QUALIFICATION ILLEGAL ON THIS CARD. 
Level 4. Card ignored. 

QUALIFICATION SECTION NESTING CAPACITY EX- 
CEEDED. 

Level 4. 

QUALIFICATION SECTION NESTING ERROR. 
Level 4. 

QUALIFICATION SECTION TERMINATED BY -ENDQ- 
CARD WITH BLANK VARIABLE FIELD. 

Level 1. Innermost qualification eliminated. 

QUALIFICATION SECTION TERMINATED BY -ENDQ- 
WITH WRONG NAME. 

Level 4. 

SERIALIZATION GROUP ON -LBL- CARD TOO LARGE. 
FIRST EIGHT CHARACTERS USED. 
Level 1. 

SIGNIFICANT DIGITS LOST IN SHIFTING FIXED POINT 
LITERAL OR CONSTANT. 

Level 2. 

SUBFIELD IGNORED BECAUSE OF FORMAT ERROR. 
Level 2. Caused by two left parentheses with no inter- 
vening right. 

SUBFIELD ****** FORMAT ERROR ON -LABEL- CARD. 

Level 2. 

S-VALUE INDETERMINATE. ASSEMBLER OR MACHINE 
ERROR. 

Level 4. 

SYMBOL TOO LONG. FIRST SIX CHARACTERS USED. 
Levels 1 and 4. 

TAG NOT ALLOWED. 

Level 1. Zero used for tag. 

TAG NOT EXPECTED. 
Level 1. Tag used. 

TAG REQUIRED. 

Level I. Zero used for tag. 
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THIS CARD NOT EFFECTIVE IN AN ABSMOD AS- 
SEMBLY. 

Level 1. 

THIS CARD NOT EFFECTIVE IN A RELMOD ASSEMBLY. 
Level 1. 

THIS CARD NOT EFFECTIVE UNLESS WITHIN A 
MACRO DEFINITION. 
Level 1. 

THIS INSTRUCTION CANNOT HAVE AN ASSOCIATED 
SYMBOL. 

Level 1. Symbol ignored. 

TOO MANY SUBFIELDS ON -DUP- CARD. FIRST TWO 
USED. 

Level 3. 

TOO MANY SUBFIELDS ON THIS CARD. 
Levels 1 and 2. Excess subfields ignored. 



TOTAL BIT COUNT FOR -OPVFD- MUST NOT EX- 
CEED 36. 

Level 3. Card ignored. 

VARIABLE FIELD FORMAT ERROR FOR -IFF- OR -IFT- 
CARD. 

Level 4. Card ignored. 

VARIABLE FIELD TOO COMPLEX. SIMPLIFY AND RE- 
ASSEMBLE. 
Level 3. 

VARIABLE FIELD TOO LONG. 

Level 4. Variable field truncated to 127 operands. 

VIRTUAL CANNOT APPEAR IN -END- OR -TCD- CARD. 
Level 2. Control section value used. 

VIRTUAL CANNOT APPEAR IN TAG. 
Level 1. Zero used for tag. 

ZERO SUPPLIED FOR REQUIRED OPERAND. 
Level 1. 
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Load-Time Debugging Processor Error Messages 



Following is an alphabetic list of Load-Time De- 
bugging Processor error messages. The symbol "******" 
in a message indicates the location where the processor 
will insert variable information. 

*** BCI STRING NOT TERMINATED BY '. TERMINATED 
BY END OF CARD. 
Self-explanatory. 

*** CAUTION. THIS * REDEF CARD DEFINES SYMBOLS 
FOR REQUESTS AFTER THIS CARD AND NOT BEFORE. 
Self-explanatory. 

CK2 READ ERROR. DUMP TRANSLATION STOPPED. 

This is a message from the postprocessor routines and it 
indicates that the routines cannot process further dump 
information. 

*** COLUMNS 1-5 SHOULD BE BLANK ON CONTINUA- 
TION CARDS (IGNORED). 
Self-explanatory. 

*** CONDITIONAL NOT FOLLOWED BY UNCONDI- 
TIONAL STATEMENT DELETED. 

This message indicates that an IF or an ON statement 
is not followed bv an unconditional action, such as SET 
or DUMP. 

*** *DEND CARD SIMULATED. *** 
Self-explanatory. 

*** DUPLICATE LIST NUMBERS. 
Self-explanatory. 

*** DUPLICATE STATEMENT NUMBERS. 
Self-explanatory. 

END OF DUMP RECORD NOT ENCOUNTERED, DUMP 
INFORMATION MAY BE INCOMPLETE. 

This is a message from the postprocessor routines and 

indicates an irregular job termination. 

*** ERROR APPROXIMATELY AT V. 

The following output appears after this message: 

V 

where the V is an arrow pointing to the approximate 
part of the source statement, represented by the line of 
X's, in which an error occurred. 

*** *ETC CARD SHOULD HAVE COLUMNS 1-5 BLANK 
(IGNORED). 

Self-explanatory. 

*** EXECUTION TERMINATED DUE TO NESTED 

DEBUG REQUESTS. 

Either a debugging request CALL has been made to 
a subroutine which in turn executes another debugging 
request, or a trap has occurred during the execution of 
a debugging request and the routine to which control 
is thereby passed executes another debugging request. 
Pairs of requests in such a relationship are called 
"nested." The above message is connected with a 
message occurring later in the output, "*** NESTED 
DEBUG REQUESTS." 



*** EXTRA RIGHT PARENTHESIS IN SET STATEMENT. 
IGNORED. 

Self-explanatory. 

*** GO TO NOT FOLLOWED BY STATEMENT NUMBER. 
DELETED. 

*** IBDBL ENCOUNTERED $-CARD. 
Self-explanatory. 

*** IBDBL TERMINATED BY UNEXPECTED EOF. 
Self-explanatory. 

*** ILLEGAL CALL ARGUMENT. STATEMENT DE- 
LETED. 

Self-explanatory. 

*** ILLEGAL CARD. SKIPPING TO NEXT LEGAL *-CARD. 
Self-explanatory. 

*** ILLEGAL INSERTION POINT. DELETED. 
Self-explanatory. 

*** ILLEGAL LIST ELEMENT. ELEMENT DELETED. 
Self-explanatory. 

*** ILLEGAL MODE IN AREA DUMP SPECIFICATION. 
OCTAL ASSUMED. 

Self-explanatory. 

*** ILLEGAL NAME FIELD. DEFINITION DELETED. 
Self-explanatory. 

*** ILLEGAL ON STATEMENT. STATEMENT DELETED. 
S elf -explanatory . 

*** ILLEGAL OPTION ON $IBDBL CARD. OPTION 
IGNORED. 

Self-explanatory. 

*** ILLEGAL *REDEF FIELD. DEFINITION DELETED. 
Self-explanatory. 

*** ILLEGAL STATEMENT. STATEMENT DELETED. 
Self-explanatory. 

*** INTEGER TOO BIG FOR STATEMENT NUMBER. 
DELETED. 

Self-explanatory. 

INVALID INFORMATION ENCOUNTERED ON SYSCK2. 
DUMP TRANSLATION STOPPED. 
Self-explanatory. 

*** LEFT HAND SIDE OF SET IS ILLEGAL. DELETED. 
Self-explanatory. 

*** LEFT PARENTHESIS IS UNMATCHED. 
Self-explanatory. 

*** LEFT PARENTHESIS MISSING IN CALL STATE- 
MENT. IGNORED. 

Self-explanatory. 

*** LEFT PARENTHESIS MISSING IN IF STATEMENT. 
IGNORED. 

Self-explanatory. 
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LINE MAX EXCEEDED. 

This is a message from the postprocessor routines. This 
message indicates that no more information will be 
dumped because the programmer-specified LINE MAX 
has been exceeded. 

*** LIST NUMBER IS UNDEFINED. 

Self-explanatory. 

*** LIST STATEMENT HAS NO NUMBER. 
Self-explanatory. 

*** LIST STATEMENT MAY NOT REFER TO ANOTHER 
LIST. REFERENCE DELETED. 
Self-explanatory. 

*** NESTED DEBUG REQUESTS. 

FIRST REQUEST AT *****, REL LOC *****, ABS LOC 

***** txt r)jrr;|f ***** 

SECOND REQUEST AT *****, REL LOC *****, ABS LOC 
***** jxt T)'p'r;j£ ***** 

The variable information after the word "AT" in each 
half of the message refers to the symbolic location of 
the request point in the format symbol + k. This 
message is connected with a message that appears 
earlier in the debugging output, "*** EXECUTION 
TERMINATED DUE TO NESTED DEBUG RE- 
QUESTS." 



*** RIGHT HAND SIDE OF SET IS ILLEGAL. DELETED. 
Self-explanatory. 

*** RIGHT PARENTHESIS MISSING IN CALL STATE- 
MENT. IGNORED. 

Self-explanatory. 

*** RIGHT PARENTHESIS MISSING IN IF STATEMENT. 
IGNORED. 

Self-explanatory. 

*** STATEMENT NUMBER ****** IS UNDEFINED. 
Self-explanatory. 

*** SYMBOL HAS MORE THAN 6 CHARACTERS. TRUN- 
CATED TO ******. 

Self-explanatory. 

*** SYSCK2 IS NOT ATTACHED. JOB WILL RUN WITH- 
OUT DEBUGGING. 

Self-explanatory . 

*** TEXT BAD. DEBUG INSERTIONS DELETED. 

All debug statements following the previous *DEBUG 
card are erroneous; therefore, this *DEBUG card and 
all debug statements following it are deleted. 

TRAP MAX REACHED. 

This is a message from the interpreter routines. This 
message indicates that no further debugging will take 
place. 
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Loader Error Messages 



The following alphabetical list contains the messages 
generated by the Loader. A row of asterisks appears 
wherever the Loader inserts a word of variable content. 
When a message begins with variable information, the 

1 . . 1 1 1 1 . • 11 1 . 1 . -IT 

me c sa2e is iisteci ai r *naDetican^ 7 d w me nexr nonvanaoie 
word. Thus, if a message cannot be found in the list 
alphabetically by the first word, the programmer should 
look for the message listed alphabetically by the second 
word. 

A SUBROUTINE TO BE INSERTED HAS THE SAME 
NAME AS AN EXISTING SUBROUTINE WHICH HAS NOT 
BEEN DELETED. 

Self-explanatory. 

A permanent redundancy occurred in the loading of final 
text overflow tape. 

CALL TO OBJECT PROGRAM UNDEFINED. 

The absolute location of the first instruction in the object 
program could not be identified. 

$***** CARD ENCOUNTERED, RETURNING TO MONI- 
TOR FOR PROCESSING OF THIS CARD. 

Either a $JOB, $IBSYS, $EXECUTE, or $STOP card 

was encountered. 

CONTROL DICTIONARY CONTAINS UNDEFINED VIR- 
TUAL. 

This message is printed only if LOGIC is specified and 
the control dictionary contains an undefined virtual. 

CONTROL SECTION '******' IS AN UNDEFINED ENTRY 
POINT. 

A section specified on the $ENTRY card does not exist. 

CONTROL SECTION '******' REQUIRED BY SUBROU- 
TINE <******' IS VIRTUAL IN THE SUBROUTINE 
LIBRARY. 

Self-explanatory. 

CONTROL SECTION '******' SPECIFIED ON A $USE 
CARD WAS DELETED, TEXT ERRORS MAY OCCUR. 

A section specified on a $USE card was nested within a 

section deleted by equality reduction. 

CYLINDER COUNT SPECIFIED FOR FILE 
<******************, E xcEEDS DISK LIMITS. THE MAX- 
IMUM WILL BE USED. 

A maximum of 250 cylinders is permitted on a $FILE 

card for a disk file. 

CYLINDER COUNT SPECIFIED FOR FILE 
<******************> E xcEEDS DRUM LIMITS. THE MAX- 
IMUM WILL BE USED. 

A maximum of 10 cylinders is permitted on a $FILE 

card for a drum file. 

DECK '******' DOES NOT EXIST IN SOURCE INPUT. 
SOMIT ENTRY IS IGNORED. 

A $OMIT specification is in error. 

DECK *******' DOES NOT EXIST IN SOURCE INPUT, SEC- 
TION RENAMED IS IGNORED. 

A $NAME specification is in error. 



DECK '******' DOES NOT EXIST IN SOURCE INPUT. 
$USE ENTRY IS IGNORED. 

A $USE specification is in error. 

DECK FORMAT ERROR - PROCESSING DECK *******' A 
CARD SEQUENCE BREAK IN ****** SEQUENCE NUM- 

T3T7T) ****** 
JJAJJ.V 

The input deck contains an error in sequence numbers. 
DECK FORMAT ERROR - PROCESSING DECK '******' A 
CARD SEQUENCE BREAK IN ****** SEQUENCE NUM- 
BER ****** THE LAST CORRECT CARD IS ****** SE- 
QUENCE NUMBER ******. 

Self-explanatory. 
DECK FORMAT ERROR - PROCESSING DECK '******' 
****** BINARY CARD IS NOT IN PROPER PLACE. CAN- 
NOT FOLLOW ****** CARD. 

A binary card improperly follows BCD card. 
DECK FORMAT ERROR - PROCESSING DECK '******' 
****** BINARY CARD IS NOT IN PROPER PLACE. THE 
LAST CORRECT CARD IS ****** SEQUENCE NUMBER 

A binary card improperly follows a binary card. 
DECK FORMAT ERROR - PROCESSING DECK '******' 
CARD IS NOT IN PROPER PLACE. THIS CARD IGNORED 
CANNOT FOLLOW ****** CARD. 

A BCD card improperly follows a BCD card. 
DECK FORMAT ERROR - PROCESSING DECK '******' 
CARD IS NOT IN PROPER PLACE. THE LAST CORRECT 
CARD IS *****- SEQUENCE NUMBER******. 

A BCD card improperly follows a binary card. 
DECK FORMAT ERROR - PROCESSING DECK '******' 
CHECKSUM ERROR -DOES NOT COMPARE IN BITS 



************ 



Self-explanatory. 
DECK FORMAT ERROR - PROCESSING DECK '******' 
CHECKSUM ERROR -DOES NOT COMPARE IN BITS 
************ THE LAST CORRECT CARD IS *****- SE- 
QUENCE NUMBER ******. 

Self-explanatory. 

DECK FORMAT ERROR - PROCESSING DECK '******' 
************ IS AN ILLEGAL 9L FORMAT. 

Absolute decks and Prest decks cannot be processed by 

the Loader. 

DECK FORMAT ERROR - PROCESSING DECK '******' 
************ IS AN ILLEGAL 9L FORMAT. THE LAST 
CORRECT CARD IS ****** SEQUENCE NUMBER ******. 

Absolute decks and Prest decks cannot be processed by 

the Loader. 

DECK FORMAT ERROR - PROCESSING DECK '******' 
TEXT ENCOUNTERED IN READING CONTROL INFOR- 
MATION. 

Subroutine library format error-text should not appear in 
control information file. Probable machine error during 
library edit. 

DECK ****** IS ASSEMBLED FOR IBM 7094 AND CAN- 
NOT BE RUN ON IBM 7090. 
Self-explanatory. 

DECK NAME APPEARING ON THE ABOVE CARD DOES 
NOT AGREE WITH NAME FROM $IBLDR CARD. 

All BCD cards ($IBLDR, $FDICT, $TEXT, $CDICT, 
$DDICT, and SDKEND) must contain the same deck 
name in columns 8-13. 
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DECKNAME CONTAINS ILLEGAL CHARACTER OR 
BLANK. A DECKNAME OF ALL BLANKS WILL BE USED. 
The deck name on $IBLDR card is missing or in error. 
A parenthesis, slash, quotation mark, equal sign, or em- 
bedded blanks are not permitted. 

DECK NAME '******' ON $GROUP CARD IS IGNORED. 
Self-explanatory. 

DECK NAME '******' ON $POOL CARD IS IGNORED. 
Self-explanatory. 

DECK NAME ON $TEXT OR $DKEND CARD UNRECOG- 
NIZABLE. 

No $IBLDR card appeared with the above name. 

DISREGARD MOUNTING INSTRUCTIONS. 

This message is printed on-line when execution is sup- 
pressed after file list has been printed on-line. 

END OF FILE IN READING INPUT (GO) TAPE. 

End of file on input tape instead of or immediately fol- 
lowing the $IBJOB card. 

END OF FILE NOT PERMITTED AT THIS POINT. 

Input to the Loader is incomplete because of a probable 
setup error. An end of file may not be embedded within 
a deck, or before the first $IBLDR card or $INCLUDE 
card within a link. 

END OF TAPE CONDITION OCCURRED IN WRITING 
'SUBROUTINE LIBRARY'. 
Retry subroutine edit. 

ENTRY POINT SPECIFIED IS NOT IN MAIN LINK. 

An initial transfer to other than the main link is not 
permitted. 

ERROR IN COMPLEX OPERATOR AT REL LOC xxxxx, 
TEXT FOLLOWING MAY BE IN ERROR. (DECK 
'DECKNM'). 

Invalid binary text, probable machine error. 

ERROR IN COMPLEX RESULT STORAGE REF AT REL 
LOC xxxxx, TEXT FOLLOWING MAY BE IN ERROR. 
(DECK 'DECKNM'). 

Invalid binary text, probable machine error. 

ERROR IN FILE NAME ENCOUNTERED ON A $LABEL 
CARD. THE CARD WILL BE IGNORED. 
Self-explanatory. 

ERROR IN VARIABLE FIELD OF ABOVE CARD. THE 
FIELD IS IGNORED. 
Self-explanatory. 

$ETC CARD NOT FOLLOWING $FILE CARD WHEN RE- 
QUIRED. ERRORS MAY OCCUR. 
Self-explanatory. 

$FILE CARD ACTIVITY SPECIFIED EXCEEDS 99. THIS 
MAXIMUM WILL BE USED. 
Self-explanatory. 

FILE ******************_ 72Q UNITS ONLY MAY BE 
USED WHEN ALTIO OPTION IS SPECIFIED. 
Self-explanatory. 

FILE <******************' BASE OF 'BLOCK SIZE A MUL- 
TIPLE OF' IS INCONSISTENTLY SPECIFIED. 

File dictionaries from different decks do not agree on the 

blocksize definition. 

$FILE CARD BLOCK SIZE SPECIFIED EXCEEDS 9999. 
THIS MAXIMUM WILL BE USED. 
Self-explanatory. 



FILE ****************** CHANNEL IS ILLEGITIMATE. 
The channel specified cannot be used. 

FILE CHECK-FILE '******************' DEVIATION 
FROM BASE OF 'BLOCK SIZE A MULTIPLE OF'. 

The file dictionary blocksize does not agree with the 

$FILE card for the same file. 

FILE CHECK-FILE '******************' DEVIATION 
FROM 'EXACT BLOCK SIZE.' 

The file dictionary blocksize does not agree with the 

$FILE card for the same file. 

FILE CHECK-FILE <******************' DEVIATION 

FROM FILE TYPE. 

The file type (input, output, checkpoint) in the file dic- 
tionary does not agree with the $FILE card for the same 
file. 

FILE CHECK-FILE <******************' DEVIATION 
FROM 'MINIMUxM BLOCK SIZE'. 

The file dictionary blocksize does not agree with the 

$FILE card for the same file. 

FILE CHECK-FILE <******************' DEVIATION 
FROM MIXED MODE. 

The file dictionary does not agree with the $FILE card 

for the same file. 

FILE CHECK-FILE <******************' DEVIATION 
FROM MODE. 

The file dictionary does not agree with the $FILE card 

for the same file. 

FTT.F. CHFCK-FTT.F. '******************' DEVIATION 
FROM UNIT ASSIGNMENT (CARD UNIT NOT AL- 
LOWED). 

Self-explanatory. 

FILE CHECK-FILE '******************' DEVIATION 
FROM UNIT ASSIGNMENT (TAPE UNIT NOT AL- 
LOWED). 

Self-explanatory. 

FILE <******************' DISK MODULE REQUESTED 
IS NOT AVAILABLE. 
Self-explanatory. 

FILE <******************> DRUM MODULE REQUESTED 
IS NOT AVAILABLE. 
Self-explanatory. 

FILE <******************> < EX ACT BLOCKSIZE' IS INCON- 
SISTENTLY SPECIFIED. 

File dictionaries from different decks do not agree on 

blocksize definition. 

FILE <******************' ILLEGAL SECONDARY UNIT 

(REQUEST IS IGNORED). 

The secondary unit may not be card equipment, disk, or 
internal file. The secondary unit must be compatible 
with primary unit: '*' may not be used to specify second- 
ary unit when primary unit is an intersystem reserve unit. 

FILE <******************' ILLEGAL SYSUNI CODE. 
A machine or system error. 

FILE «*•********■********' INTERSYSTEM INPUT FILE 
HAS NOT BEEN RESERVED. 
Self-explanatory. 

FILE <******************' i/o UNIT TYPE REQUIREMENT 
IS INCONSISTENTLY SPECIFIED. 

File dictionaries from different decks do not agree on an 

input/output unit type. 

FILE '******************' MODE OR FILE I/O TYPE IS IN- 
CONSISTENTLY SPECIFIED. 

File dictionaries from different decks do not agree. 
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FILE <******************' no UNIT IS ASSIGNED TO 
****** (REQUEST IS IGNORED). 
Self-explanatory. 

FILE <******************> PRINTER ILLEGAL AS AN 
INPUT 

Self-explanatory. 

FILE <******************' PROCESSING ERROR. 

Machine or system error during unit assignment. 
FILE <******************> puNCH ILLEGAL AS AN IN- 
PUT. 

Self-explanatory. 

FILE <******************' READER ILLEGAL AS AN OUT- 
iMJ'l'. 

Self-explanatory. 

FILE RENAME FOR FILE <******************' is IG- 
NORED. DECK '******' DOES NOT EXIST. 
Self-explanatory. 

FILE RENAME FOR FILE ****************** IS IG _ 
NORED. FILE DOES NOT EXIST IN ANY FILE DIC- 
TIONARIES. 

Self-explanatory. 

FILE RENAME FOR FILE ****************** is IG- 
NORED. FILE DOES NOT EXIST IN DECK •'******'. 
Self-explanatory. 

FILE <******************' RESERVE UNIT NAME IS IL- 
LEGAL. 

Intersystem reserve channels are designated by letters J 
through Q. Unit numbers range from through 9. 

FILE <******************> SPECIFIED AS NOPOOL IS REF- 
ERENCED RY A $POOL OR $GROUP CARD. NOPOOL IS 
IGNORED. 

Self-explanatory. 

FILE <******************. SPECIFIED ON $GROUP CARD 
DOES NOT EXIST. 

Self-explanatory. 

FILE '***** ********> SPECIFIED ON $LABEL CARD 

DOES NOT EXIST. 

Self-explanatory. 
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DOES NOT EXIST. 

Self-explanatory. 

FILE '******************' UNIT ****** ILLEGAL AS AN 
INPUT. 

Self-explanatory. 

FILE '******************' UNIT ****** ILLEGAL AS AN 
OUTPUT. 

Self-explanatory. 

FILE '******************' UNIT ****** ILLEGAL FOR 
BCD MODE USE (STANDARD OPTION IS ASSUMED). 
File mode is binary. 

FILE '******************' UNIT ****** ILLEGAL FOR 
BINARY MODE USE (STANDARD OPTION IS ASSUMED). 
File mode is BCD. 

F IL E '******************> tj\IT ****** IS A\ T TITFCAT 
SECONDARY UNIT (REQUEST IS IGNORED), SECOND 
UNIT ASSIGNED SAME AS FIRST. 

The secondary unit may not be card equipment, disk, or 
internal file. The secondary unit must be compatible with 
primary unit. '*' may not be used to specify secondary 
unit when primary unit is an intersystem reserve unit. 

FILE '******************' UNIT ****** \OT ALLOWED 
FOR LABELLED FILE USE. 
Self-explanatory. 



FILE <******************' UNIT REQUESTED IS NOT 
AVAILARLE. 

Self-explanatory. 

FILE <******************' UNIT2 CHANNEL IS ILLEGIT- 
IMATE (REQUEST IS IGNORED). 

The channel specified cannot be used. 

FILE <******************> UNIT2 REQUESTED IS NOT 
AVAILABLE (REQUEST IS IGNORED). 

Self-explanatory. 

FIRST CARD READ FROM 'INPUTV'GO TAPE' IS NOT A 
$IBJOB CARD. 

Probable machine error. 

FORMAT ERROR ENCOUNTERED ON A $LABEL CARD. 
THE CARD WILL BE IGNORED. 

Self-explanatory. 

FORMAT ERROR ENCOUNTERED ON A $SIZE CARD. 
THE CARD WILL BE IGNORED. 
Self-explanatory. 

FORMAT ERROR FOR FIELD <******' OF $NAME CARD. 
THE REMAINDER OF THIS CARD AND ASSOCIATED 
$ETC CARDS WHICH FOLLOW WILL BE IGNORED. 
Self-explanatory. 

FORMAT ERROR FOR FIELD '******' OF $OMIT CARD. 
THE REMAINDER OF THIS CARD AND ASSOCIATED 
$ETC CARDS WHICH FOLLOW WILL BE IGNORED. 

Self-explanatory. 

FORMAT ERROR FOR FIELD '******' OF $USE CARD. 
THE REMAINDER OF THIS CARD AND ASSOCIATED 
$ETC CARDS WHICH FOLLOW WILL BE IGNORED. 
Self-explanatory. 

SGROUP CARD BUFFER COUNT SPECIFIED EXCEEDS 
999. THE FIELD WILL BE OMITTED. 
Self-explanatory. 

$GROUP CARD OPEN FILE COUNT SPECIFIED EX- 
CEEDS 99. THE FIELD WILL BE OMITTED. 
Self-explanatory. 

$IBLDR CARD ENCOUNTERED WHICH SPECIFIES 
'LIBE' DURING PROCESSING OF 'NOLIBE' OPTION 
CARDS ONLY. THE CARD WILL BE IGNORED. 

Mixture of 'LIBE' and 'NOLIBE' decks is not permitted. 

$IBLDR CARD ENCOUNTERED WHICH SPECIFIES 'NO- 
LIBE' DURING PROCESSING OF 'LIBE' OPTION CARDS 
ONLY. THE CARD WILL BE IGNORED. 

Mixture of 'LIBE' and 'NOLIBE' decks is not permitted. 

$IBLDR CARD ENCOUNTERED WHILE PROCESSING 
SUBROUTINE WHICH HAS THE SAME NAME AS 
$IBLDR CARD FROM SOURCE INPUT WHERE 'LIBE' 
OPTION WAS NOT SPECIFIED. 

Duplicate deck names are not permitted. 

$IBLDR CARD WITH DUPLICATE NAME ENCOUN- 
TERED WHILE PROCESSING SOURCE INPUT. 
Duplicate deck names are not permitted. 

ILLEGAL BCD VALUE ENCOUNTERED ON A $ETC 
CARD FOLLOWING A SFILE CARD. THE $FILE CARD 
AND ASSOCIATED $ETC CARDS WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL BCD VALUE ENCOUNTERED ON A $ETC 
CARD FOLLOWING A SGROUP CARD. THE $GROUP 
CARD AND ASSOCIATED $ETC CARDS WILL BE 
IGNORED. 

Self-explanatory. 
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ILLEGAL BCD VALUE ENCOUNTERED ON A $ETC 
CARD FOLLOWING A $POOL CARD. THE $POOL CARD 
AND ASSOCIATED $ETC CARDS WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL BCD VALUE ENCOUNTERED ON A $FILE 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS 
WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL BCD VALUE ENCOUNTERED ON A $GROUP 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS 
WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL BCD VALUE ENCOUNTERED ON A $POOL 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS 
WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL CHARACTER ENCOUNTERED ON A $ETC 
CARD FOLLOWING A $FILE CARD. THE $FILE CARD 
AND ASSOCIATED $ETC CARDS WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL CHARACTER ENCOUNTERED ON A $ETC 
CARD FOLLOWING A $GROUP CARD. THE $GhOUP 
CARD AND ASSOCIATED $ETC CARDS WILL BE 
IGNORED. 

Self-explanatory. 

ILLEGAL CHARACTER ENCOUNTERED ON A $ETC 
CARD FOLLOWING A $POOL CARD, THE SPOOL CARD 
AND ASSOCIATED $ETC CARDS WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL CHARACTER ENCOUNTERED ON A $FILE 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS WILL 
BE IGNORED 

Self-explanatory. 

ILLEGAL CHARACTER ENCOUNTERED ON A $GROUP 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS WILL 
BE IGNORED. 

Self-explanatory. 

ILLEGAL CHARACTERS ENCOUNTERED ON A $POOL 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS WILL 
BE IGNORED. 

Self-explanatory. 

ILLEGAL CHARACTER. REMAINDER OF CARD IG- 
NORED. 

$ORIGIN or $INCLUDE card contains an invalid char- 
acter or a blank in column 16. 

ILLEGAL FILE NAME ENCOUNTERED ON A $ETC CARD 
FOLLOWING A $FILE CARD. THE $FILE CARD AND 
ASSOCIATED $ETC CARDS WILL BE IGNORED. 

Self-explanatory. 

ILLEGAL FILE NAME ENCOUNTERED ON A $ETC CARD 
FOLLOWING A $GROUP CARD. THE $GROUP CARD AND 
ASSOCIATED $ETC CARDS WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL FILE NAME ENCOUNTERED ON A $ETC CARD 
FOLLOWING A $POOL CARD. THE $POOL CARD AND 
ASSOCIATED $ETC CARDS WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL FILE NAME ENCOUNTERED ON A $FILE 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS 
WILL BE IGNORED. 

Self-explanatory. 



ILLEGAL FILE NAME ENCOUNTERED ON A $GROUP 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS WILL 
BE IGNORED. 

Self-explanatory. 

ILLEGAL FILE NAME ENCOUNTERED ON A $POOL 
CARD. THIS CARD AND ASSOCIATED $ETC CARDS 
WILL BE IGNORED. 
Self-explanatory. 

ILLEGAL SECTION NAME ENCOUNTERED ON A 
$ENTRY CARD. THE CARD WILL BE IGNORED. 

The section name specified on the $ENTRY card may not 
contain a parenthesis, equal sign, quotation mark, comma, 
or slash. 

IMPROPER FORMAT. 

Leading, trailing, or multiple field separators occur in 
the variable field of the $ORIGIN or $INCLUDE card. 

IMPROPER SYMBOLIC ORIGIN. 

The symbolic origin on a $ORIGIN card is all numeric 
or greater than six characters. 

INCOMPLETE DDICT ENTRY IN DECK '******'. 

More debugging dictionary binary cards are expected 
before $DKEND card. 

INPUT/OUTPUT ERROR - BLOCK SEQUENCE FAILURE 
AND PERMANENT REDUNDANCY OCCURRED IN READ- 
ING GENERATED TIF. 

Probable machine error. 

Tis.TT)TTT//^.TT'nDTTT' vrrqR — BLOCK SEQUENCE FAILURE 
AND PERMANENTREDUNDANCY OCCURRED IN READ- 
ING INTERMEDIATE TEXT. 
Probable machine error. 

INPUT/OUTPUT ERROR - BLOCK SEQUENCE FAILURE 
AND PERMANENT REDUNDANCY OCCURRED IN READ- 
ING LIBRARY CTRL FILE. 

Probable machine error. 

INPUT/OUTPUT ERROR - BLOCK SEQUENCE FAILURE 
AND PERMANENT REDUNDANCY OCCURRED IN READ- 
ING LIBRARY SRNT/SRDT. 

Probable machine error. 

INPUT/OUTPUT ERROR - BLOCK SEQUENCE FAILURE 
AND PERMANENT REDUNDANCY OCCURRED IN READ- 
ING LIBRARY TEXT FILE. 
Probable machine error. 

INPUT/OUTPUT ERROR -END OF BUFFERS CONDI- 
TION OCCURRED IN READING GENERATED CIF. 
Probable machine error. 

INPUT/OUTPUT ERROR -END OF BUFFERS CONDI- 
TION OCCURRED IN READING GENERATED TIF. 
Probable machine error. 

INPUT/OUTPUT ERROR - PERMANENT REDUNDANCY 
OCCURRED IN READING GENERATED CIF. 
Probable machine error. 

INPUT/OUTPUT ERROR - PERMANENT REDUNDANCY 
OCCURRED IN READING GENERATED TIF. 
Probable machine error. 

INPUT/OUTPUT ERROR - PERMANENT REDUNDANCY 
OCCURRED IN READING INTERMEDIATE TEXT. 
Probable machine error. 

INPUT/OUTPUT ERROR - PERMANENT REDUNDANCY 
OCCURRED IN READING LIBRARY CTRL FILE. 
Probable machine error. 
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INPUT/OUTPUT ERROR - PERMANENT REDUNDANCY 
OCCURRED IN READING LIBRARY SRNT/SRDT. 
Probable machine error. 

INPUT/OUTPUT ERROR - PERMANENT REDUNDANCY 
OCCURRED IN READING LIBRARY TEXT FILE. 
Probable machine error. 

INPUT/OUTPUT - END OF FILE IN READING INTER- 
MEDIATE TEXT. 

Probable machine error. 

INPUT/OUTPUT ERROR - UNEXPECTED END OF FILE 
IN READING LIBRARY CTRL FILE. 

Nonexistent subroutine or a routine which had been 
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INPUT/OUTPUT ERROR - UNEXPECTED END OF FILE 
IN READING LIBRARY TEXT FILE. 
Probable machine error. 

INSUFFICIENT STORAGE FOR CONTROL DICTION- 
ARIES AND CONTROL INFORMATION DETECTED BY 

****** 

Program is too large for the Loader to handle. Decks 
must be restructured to reduce cross referencing. 

INSUFFICIENT STORAGE TO GENERATE SUBROUTINE 
SECTION NAME TABLE AND SUBROUTINE DEPEND- 
ENCE TABLE. 

The library contains too many control sections. Some 

control sections must be deleted. 

INSUFFICIENT WORKING STORAGE. 

Decks must be restructured to reduce cross referencing. 

I/O ERROR - EOB IN WRITING FINAL TEXT. 
Probable machine error. 

I/O ERROR - TEXT - EOB. 
Probable machine error. 

I/O ERROR - TEXT PERM. REDUNDANCY. 
Probable machine error. 

LIBRARIAN CONTROL CARD WITH BLANK VARIABLE 
FIELD. 

Only $INSERT card may have blank variable field. 
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FLOW. THERE IS AN EXCESSIVE NUMBER OF UNIQUE 

CONTROL SECTION NAMES. 

Only 1,000 unique control section names are allowed in 
loading. (2,000 unique control section names are per- 
mitted by the librarian.) The Loader must be re- 
assembled. 

LOADING TERMINATED DUE TO IMPROPERLY DE- 
FINED OVERLAY STRUCTURE. 

Overlay structure could not be defined because of in- 
valid symbolic origins on one or more links. 

LOADING TERMINATED DUE TO TOO MANY VIRTUAL 

SECTIONS. 

If not a system or machine error, IBLDR must be re- 
assembled. Current limit is 350 virtual sections. 

NO DECKNAME IN SPECIFICATION ON $USE CARD. 
'******' ENTRY IS IGNORED. 
Self-explanatory. 

NON STANDARD LABEL ROUTINE FOR FILE 
<***,*********,****> WAS DELETED BY LOAD CONTROL 

CARDS. 

Self-explanatory. 

NO SYMBOLIC ORIGIN SPECIFIED. 

A symbolic origin is not first in the variable field of a 
$ORIGIN card. 



NOT ENOUGH UNITS AVAILABLE. 

This general error message is generated if there were 
not enough units to complete total unit assignment 
requests. 

'NOTEST IGNORED BECAUSE 'LIBE' OPTION IS 
SPECIFIED. 

Self-explanatory. 

NOT IB LOADER CONTROL CARD. CARD IGNORED. 
Self-explanatory. 

OBJECT PROGRAM EXCEEDS AVAILABLE STORAGE. 

Self-explanatory. 
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ON MAIN LINK $ORIGIN CARD. 

Self-explanatory. 

ORIGIN IS INCORRECTLY SPECIFIED. ORIGIN IS 
IGNORED. 

Librarian control card ($INSERT, $REPLACE, $AS- 
SIGN), used to assign an absolute origin to a Library 
routine, is incorrect. 

ORIGIN MUST BE SPECIFIED ON $ASSIGN CARD. 
Librarian control card error. 

ORIGIN SPECIFIED FOR LINK *** IS TOO LOW. LOW- 
EST ALLOWABLE FOR THIS SYSTEM CONFIGURATION 
IS ***** (OCTAL) AND HAS BEEN ASSIGNED. 

An absolute origin specified on a $ORIGIN card is too 

low. 

OVERLAY SUBROUTINE .LOVRY NOT DEFINED. 

LOVRY is required to perform overlay link loading. 

PARAMETER '******' NOT RECOGNIZED. IGNORED. 
Unrecognizable parameter found on $ORIGIN card. 

PERM REDUN IN READING INPUT (GO) TAPE. 
Probable machine error. 

$POOL CARD BLOCK SIZE SPECIFIED EXCEEDS 9999. 
THE FIELD WILL BE OMITTED. 
Self-explanatory. 

$POOL CARD BUFFER COUNT SPECIFIED EXCEEDS 
999. THE FIELD WILL BE OMITTED. 

Self-explanatory. 

POOLING ERROR GROUPING FILE ' *** '. 

Files of one group are not in the same buffer pool. 

<******' PREVIOUSLY SPECIFIED, IGNORED. 

Section or deck appears more than once on $INCLUDE 
cards for the same link. 

PROGRAM EXCEEDS ABSOLUTE LOCATION ******. 
Program may use but not load above specified value. 

PROGRAM REQUIRES IOCS, IOCS MAY NOT BE 
LOADED WHEN THE ALTIO OPTION HAS BEEN 
SPECIFIED. 

Self-explanatory. 

RELATIVE LOCATION OF TEXT CONTAINING ILLEGAL 

CONTROL GROUP. (DECK ' *'). 

A list of relative locations follows this message. 

RELATIVE LOCATION OF TEXT CONTAINING ILLEGAL 
LOCATION COUNTER CONTROL. (DECK '******'). 
Self-explanatory. 

RELATIVE LOCATION OF TEXT CONTAINING INDE- 
FINABLE FIELD. (DECK '******'). 

A list of relative locations follows this message. 
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****** REQUIRED AS A LOAD-TIME DEPENDENCY BY 
ROUTINE ***** IS VIRTUAL IN IBLIB. LIBRARIAN 
PROCESSING CONTINUES WITH THIS DEPENDENCY 
IGNORED. 

The input/output routine required from analysis of a 
SLABEL or $FILE card does not exist in the Library. 

SECONDARY $ENTRY CARD ENCOUNTERED AND 
IGNORED. 

Self-explanatory. 

SECTION ****** IS AN UNDEFINED SYSTEM SYMBOL. 
Faulty system subroutines or machine error. 

SECTION <******' DOES NOT EXIST IN DECK '******' 
$OMIT ENTRY IS IGNORED. 

A $OMIT specification is in error. 

SECTION '******' DOES NOT EXIST IN DECK '******' 
SECTION RENAME IS IGNORED. 

A $NAME specification is in error. 

SECTION '******' DOES NOT EXIST IN DECK '******' 
$USE ENTRY IS IGNORED. 

A $USE specification is in error. 

SECTION <******' DOES NOT EXIST IN SOURCE INPUT. 
$OMIT ENTRY IS IGNORED. 

A $OMIT specification is in error. 

SECTION '******' DOES NOT EXIST IN SOURCE INPUT. 
SECTION RENAME IS IGNORED. 

A $NAME specification is in error. 

SECTION '******' in DECK '******' HAS BEEN MARKED 
FOR DELETION AND CANNOT BE SPECIFIED ON $USE 
CARD. 

A $USE specification is in error. 

SECTION - 2 I/O ERROR EOB IN SRDICT. 
Probable machine error. 

SECTION - 2 I/O ERROR EOF IN SRDICT. 
Probable machine error. 

SECTION NAME OF '000000' OR '//' CANNOT BE SPECI- 
FIED. $NAME ENTRY IS IGNORED. 
Self-explanatory. 

SECTION NAME OF '000000' OR '//' CANNOT BE SPECI- 
FIED. $USE ENTRY IS IGNORED. 
Self-explanatory. 

SECTION NAME OF '000000' OR 7/' CANNOT BE SPECI- 
FIED. $OMIT ENTRY IS IGNORED. 

Self-explanatory. 

SECTION OR DECK *******' HAS BEEN SPECIFIED TO 
BE ASSIGNED TO MORE THAN ONE LINK. 

Section or deck appears on more than one $INCLUDE 
card in different links. 

SEQUENCE FAILURE IN ORDERING OF SR LIBRARY. 
Probable machine error. 

STARTING CYLINDER SPECIFIED FOR FILE 
<******************, EXCEEDS DISK LIMITS. ZERO WILL 
BE USED. 

Starting cylinder specified on a $FILE card for a disk 

file cannot exceed 249. 

STARTING CYLINDER SPECIFIED FOR FILE 
<******************> EXCEEDS DRUM LIMITS. ZERO WILL 
BE USED. 

Starting cylinder specified on a $FILE cards for a drum 
file cannot exceed 9. 

STORAGE ALLOCATION ERROR - BUFFER COUNT 
SPECIFIED ON A POOL CARD IS INSUFFICIENT. 

Number of buffers must be larger to handle the required 

number of open files. 



STORAGE ALLOCATION ERROR-INSUFFICIENT INPUT/ 
OUTPUT BUFFER STORAGE. 
Files must be pooled. 

SUBROUTINE DICTIONARY FORMAT ERROR. 

Machine or system error. 

A ) . EOF in middle of subroutine name table 

B ) . No subroutine name table 

C ) . Subroutine dependence table not complete 

D ) . Subroutine dependence table has invalid format 

1 ) Invalid operation 

2) Comma was encountered when bracket count 
not greater than zero 

3 ) Too many right brackets 

SUBROUTINE NAME IS INCORRECTLY SPECIFIED. 

Invalid format of deck name on librarian control card. 

SYMBOL '******' NOT DEFINED IN DECK '******'. 

Debugging symbol was not found in debugging diction- 
ary for this deck. Debugging activity needing this symbol 
will be ineffective. 

SYMBOL '******' NOT DEFINED IN DECK '******' DECK 

NOT ENCOUNTERED. 

A deck for which a debugging dictionary was required 
was not in this program load. Debugging activity need- 
ing this symbol will be ineffective. 

SYSTEM ERROR OR CPU MAINFRAME FAILURE. ENTRY 
IN SUBROUTINE SECTION NAME TABLE DOES NOT 
APPEAR AS REAL RETAINED SECTION IN ANY CON- 
TROL DICTIONARY. 
Self-explanatory. 

THE ABOVE CARD IS NOT A LIBARIAN CONTROL 
CARD. 

Self-explanatory. 

THE ABOVE CARD IS NOT PERMITTED IN THE LI- 
BRARY. IT IS IGNORED. 

Subroutines may not contain $USE, $OMIT, or $NAME 
cards. 

TOO MANY LEVELS SUBROUTINE DEPENDENCE. 

More than 25 dependent subroutines detected due to 
calling some subroutine. 

TOO MANY REQUIRED SUBROUTINES. 

The program uses so many subroutines from the Sub- 
routine Library that the storage allotted for the list of 
subroutine names is exhausted. This list, called the re- 
quired subroutine package number list, is described in 
"Section 2" under "Loader Information" and in "Sub- 
routine Library Information." 

UNDEFINED CONTROL DICTIONARY ENTRIES REFER- 
ENCED. 

A list of control section names always follows this 

message. 

UNDEFINED FILE <******************>. $piLE card is 
missing. 

Self-explanatory. 

UNDEFINED SECTION OR DECK NAME '******'. 

A section or deck name on a $INCLUDE card is unde- 
fined. 

UNDEFINED VIRTUAL CONTROL SECTION '******'. 
This message is not printed if LOGIC is requested. 

UNEXPECTED END OF BUFFERS CONDITION ENCOUN- 
TERED IN WRITING OF INTERMEDIATE TEXT FILE. 
Probable machine error. 

UNIT SYSxxx NOT ATTACHED AND READY. 

Unit specified for overlay links has not beeji attached to 
a physical drive. 
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UNRECOGNIZABLE PARAMETER ENOUNTERED ON A 
$FILE CARD. '******' WILL BE IGNORED. 
Self-explanatory. 

UNRECOGNIZABLE PARAMETER ENCOUNTERED ON A 
$GROUP CARD. '******' WILL BE IGNORED. 
Self-explanatory. 

UNRECOGNIZABLE PARAMETER ENCOUNTERED ON A 
$IBLDR CARD. '******' WILL BE IGNORED. 
Self-explanatory. 

UNRECOGNIZABLE PARAMETER ENCOUNTERED ON A 
SLABEL CARD. THE FIELD IS STORED AS ZERO. 
Self-explanatory. 



UNRECOGNIZABLE PARAMETER ENCOUNTERED ON A 
$POOL CARD. '******' WILL BE IGNORED. 
Self-explanatory. 

UNRECOGNIZABLE PARAMETER ON $IBJOB CARD. 
****** IS IGNORED. 
Self-explanatory. 

VALUE SPECIFIED ON $SIZE CARD EXCEEDS FIELD 
SIZE. THE CARD WILL BE IGNORED. 

Self-explanatory. 

VIRTUAL SECTION NAME LIST IS FULL. 

If not system or machine error, the Loader must be 
reassembled. Limit is 350. 
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Subroutine Library Error Messages 



The following list includes system subroutine, Fortran 
iv subroutine, and cobol subroutine error messages. 
Following each message is an explanation or a sug- 
gested action. The symbol "******" indicates the loca- 
tion in a message where the Subroutine Library inserts 
variable information. 

System Subroutine Messages 

The subroutine in which the error was encountered 
precedes each message. 

.LXCON 

****** LINES OUTPUT 
Self-explanatory. 

STR AT ***** XR1 = ***** XR2 = ***** XR4 = ***** 
This message occurs only on the IBM 7090 Oper- 
ating System and is followed by a dump. 

SYSTEM STOP XR1 = ***** XR2 = ***** XR4 = ***** 
Self-explanatory. This message occurs only on the 
IBM 7090 Operating System. 

STR AT ***** XR1 = ***** XR2 = ***** XR4 = ***** 
XR3 = ***** XR5 = ***** XR6 = ***** XR7 == ***** 
This message occurs only on the IBM 7094 Oper- 
ating System and is followed by a dump. 

SYSTEM STOP XR1 = ***** XR2 = ***** XR4 = ***** 
vpo _ ***** ypk = ***** XR6 = ***** XR7 = ***** 

Self-explanatory. 

.LOVRY 

UNABLE TO INTERPRET OVERLAY COMMUNI- 
CATION REGION WHILE LOADING LINK. CAN- 
NOT PROCEED. 

This message is generated when the overlay tables, 
.LDT, .LVEC, or .LRECT, are destroyed, or when 
a tape read error occurred while overlay tables were 
being destroyed. 



.LXSL 



.LXSEL FOR UNIT REQUESTED IS NOT IN 

LIBRARY. 

This message indicates that a reassembly is re- 
quired for the equipment requested. LXSL is a 
modular assembly based on parameters for disk/ 
drum and Hypertape. 

SYSOU, SYSIN, OR SYSPP CANNOT BE ASSIGNED 

TO DISK/DRUM. 

Since the operating system does not support periph- 
eral functions on disk or drum, .LXSL does not 
support them either. Reassignment of the function 
is required. 



FORTRAN IV Subroutine Messages 

The following list gives the subroutine in which the 
error was encountered, the error code, the error mes- 
sage, and the optional exit message. Execution is 
terminated after each error message is written unless 
the optional exit is used. The optional exit message is 



written below the error message to indicate the action 
taken before execution is resumed. ( See the discussion 
of optional exits under "fortran Utility Library." ) An 
explanation follows each error message and each 
optional exit message. 

FXP1 1 

EXPONENTIATION ERROR 0**0. 
For F where I =0, J=0. 

SET RESULT =0. 
SetI J = 0. 

FXP1 2 

EXPONENTIATION ERROR 0**(-J). 
For I J where 1=0, J<0. 

SET RESULT =0. 
SetI J = 0. 

FXP2 3 

EXPONENTIATION ERROR 0**0. 
For B J where B=0, J = 0. 

SET RESULT =0. 
SetB J = 0. 

FXP2 4 

EXPONENTIATION ERROR 0**(-J). 
For B J where B = 0, J<0. 

SET RESULT =0 
SetB J = 0. 

FXP3 5 

EXPONENTIATION ERROR (-B)**C. 
For B c where B<0, C^=0. 

EVALUATE FOR +B. 
Evaluate for | B | . 

FXP3 6 

EXPONENTIATION ERROR 0**0. 
For B c where B=0, C = 0. 

SET RESULT =0. 
SetB c =0. 

FXP3 7 

EXPONENTIATION ERROR 0**(-C). 
For B c where B = 0,C<0. 

SET RESULT =0. 
SetB c = 0. 

FXPF 8 

EXP(X), X GRT THAN 88.029692 NOT ALLOWED. 
For e x where X>88.029692. 

SET RESULT = + OMEGA. 
SETe* = +«. 

FLOG 9 

ALOG(0) ORALOG10(0) NOT ALLOWED. 
For logeX or logioX where X=0. 

SET RESULT = -OMEGA. 

Set log^X or logmX = — fi. 

FLOG 10 

ALOG ( -X) OR ALOG10 ( -X) NOT ALLOWED. 
For logeX or logioX where X < 0. 

EVALUATE FOR +X 
Evaluate for I X I. 
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FATN 11 

ATAN2 (0,0) NOT ALLOWED. 

ror arcian v *■>**■) w " e "- x "> " 

SET RESULT = 0. 
Set angle = 0. 

TTQfXr I o 

SIN(X) OR COS(X), I X I CRT THAN OR EQ TO 
2**25 NOT ALLOWED. 

For sin(x) or cos(x) where | X ^ 2 25 . 

SET RESULT = 0. 

Setsin(X) = 0orcos(X) =0. 

FSQR 13 

Sl^iIVI i x — a; i'nvvjl auuv/iiui^. 

For X 1/2 where X <0. 

EVALUATE FOR +X. 
Evaluate f or | X | . 

FDX1 14 

EXPONENTIATION ERROR 0**0. 
For D J where D = 0, J = 0. 
Also, for Z J where Z = + Oi, J = 0. 

SET RESULT =0. 

Set D J = or set V = + Oi. 

rL/Ai w 

EXPONENTIATION ERROR 0** ( -J ) . 
For D J where D = 0, J<0. 
Also, for V where Z = + Oi, J < 0. 

SET RESULT =0. 

Set D J = or set Z J = + Ot. 

FDX2 16 

EXPONENTIATION ERROR (-B)**C. 
For DA where Di<0, D 2 ^=0. 

EVALUATE FOR +B. 
Evaluate for | Di |. 

FDX2 17 

EXPONENTIATION ERROR 0**0. 
For DA where D, = 0, D 2 =0. 

SET RESULT =0. 
SetDA=0. 

FDX2 18 

EXFONENtIAtIuN uRROR 0**(-C). 
For DA where D,=0, D 2 <0. 

SET RESULT =0. 
SetDA=0. 

FDXP 19 

DEXP(X), X GRT THAN 88.029692 NOT ALLOWED. 
For e x where X>88.029692. 

SET RESULT = + OMEGA. 
Sete* = +0. 

FDLG 20 

DLOG(0) ORDLOG10(0) NOT ALLOWED. 
For logeX or logioX where X = 0. 

SET RESULT = -OMEGA. 
Set log c X or log,oX = -«. 

FDLG 21 

DLOG ( -X) OR DLOG10 ( -X) NOT ALLOWED. 
For logeX or logioX where X < 0. 

EVALUATE FOR +X. 
Evaluate f or | X | . 

FDSQ 22 

DSQRT( -X) NOT ALLOWED. 
For X * where X<0. 

EVALUATE FOR +X. 
Evaluate for | X | . 



FDSC 23 

DSIN(X) OR DCOS(X), | X | GRT THAN OR EQ TO 
PI*2**50 NOT ALLOWED. 

For sin(X) or cos(X) where | X | > 2 5 V 

SET RESULT = 0. 

Setsin(X) = Oorcos(X) = 0. 

FDAT 24 

DATAN2(0,0) NOT ALLOWED. 

For arctan ( Y,X) where Y=0, X=0. 
SET RESULT =0. 
Set angle = 0. 

FCXP 26 

CEXP(X + IY), X GRT THAN 88.029692 NOT 
ALLOWED. 

For e X+1Y where X>88.029692. 
SET RESULT = OMEGA* ( COSY +ISINY) 
Sete x+,T = fi[cos(Y) + isin(Y)]. 

FCXP 27 

CEXP(X+IY), | Y | GRT THAN OR EQ TO 2**25 NOT 

ALLOWED. 

For e x+,T where |Y|>2 25 . 

SET RESULT = + 01. 
Set e x+iT = + Oi. 

FCLG 28 

CLOG(0+0I) NOT ALLOWED. 

For log e (X + iY) where X=0, Y=0. 

SET RESULT = -OMEGA + 01. 
Setlog e (X+iY) = -O+0i. 

FCSC 29 

CSIN(X+IY) OR CCOS(X + IY), | X | GRT THAN OR 
EQ TO 2**25 NOT ALLOWED. 

For sin(X + iY) or cos(X + iY) where | X | > 2* 

SET RESULT = + 01. 

Set sin(X + iY) or cos(X + iY) = + Oi. 

FCSC 30 

CSIN (X + IY) OR CCOS (X+IY), | Y | GRT THAN 
88.029692 NOT ALLOWED. 

For sin(X + iY) or cos(X + iY) where | Y | > 

88.029692. 
REF IBLIB ERR MSG LIST FOR EVALUATION 
METHOD. 

a 

For Y > 88.029692, sin(X + iY) = ^ (sin X + 

Q 

icos X) and cos (X + iY) = ^ ( cos X-isin X). 

Q 
For Y < -88.029692, sin (X + iY) = ^ (sin X - 

icos X) and cos (X + iY) = g (cos X+isin X). 

FIOH 31 TTAC 

FORMAT AT xxxxxx, FIRST WORD xxxxxx, HAS 
ILLEGAL CONTROL CHARACTER OR SPECIFIED 
TOO LONG A LINE. 

Either invalid control character in FORMAT state- 
ment or too long a line is specified. 
TREAT AS END OF FORMAT. 

FCNV 32 

ILLEGAL CHAR IN DATA BELOW OR BAD 
FORMAT. 

Record containing invalid character written on-lme 

following message. 
TREAT ILLEGAL CHARACTER AS ZERO. 

FCNV 33 

ILLEGAL CHAR IN DATA BELOW OR BAD 

FORMAT. 

Record containing invalid character written on-lme 

following message. 
TREAT ILLEGAL CHARACTER AS ZERO. 
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FIOS. 



FIOB 



FIOB 



FIOB 



FIOS 
FIOS. 



FIOS 
FIOS. 



FIOS 



35 
PERMANENT READ REDUNDANCY UNITxxx. 

or 
RECORD USED AS READ 100TH TIME. 

38 

PHYSICAL RECORD SIZE EXCEEDS BUFFER SIZE. 
This message pertains to binary input data. 

PROCESS PORTION OF RECORD IN BUFFER. 

39 

INTERNAL LABEL WORD COUNT DOES NOT 
MATCH IOCS WORD COUNT, 
or 

PROCESS RECORD READ. 

40 
LIST EXCEEDS LOGICAL RECORD LENGTH. 

or 
STORE ZEROS IN REMAINING LIST ITEMS 

} « 

END OF FILE READING UNITxx. 

or 
READ NEXT FILE. 

I 42 

PERMANENT READ REDUNDANCY UNITxx. 

or 
RECORD USED AS READ THE 100th TIME. 

43 



or 



NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOS 44 

END-OF-BUFFER EXIT WRITING UNITxx. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FRCD 46 

END-OF-FILE CARD READER. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FVI ° I 
FVIO.} 47 

LOGICAL UNIT NOT DEFINED FOR VALUE xx. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FBST 48 

PERMANENT READ REDUNDANCY UNITxx. 

or 
RECORD USED AS READ THE 100th TIME. 

FBST 49 

END-OF-BUFFER EXIT READING UNITxx. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FDMP 50 

TAPE REDUNDANCY ON SYSUT4 ATTEMPTING 
TO WRITE MEMORY SAVE. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

ir"CT TTr r-i 

ioi_ixixii oi 

REFERENCE TO NONEXISTENT SENSE LIGHT. 

( a ) For I larger than 4 when setting the sense light. 

( b ) For I equal to or larger than 4 when testing 
the sense light. 
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DECLARED 'OFF' IF TESTING. IGNORED IF SET- 
TING. 

( a ) No action is taken. 

(b) Set J equal to 2 (OFF). 

FIOU 52 

PUNCTUATION ERROR OR ZERO SUBSCRIPT. 

NO OPTIONAL EXIT-EXECUTION TERMINATED. 
Results from error conditions during read of BCD 
data referencing NAMELIST due to punctuation 
error in variable name, subscript, or literal, or to 
absence of a literal. 

FSSWTH 53 

NONEXISTENT SENSE SWITCH TESTED. 
For I equal to or larger than 6. 

SWITCH DECLARED 'UP'. 
Set J equal to 2 (OFF). 



FIOS 
FIOS. 



J 54 

WRITE REQUEST ON UNIT DEFINED AS SYSIN1 

ILLEGAL. 

NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FXEM 55 

ILLEGAL VALUE FOR COMPUTED GO TO AT 
IFN xxxxx. EXECUTION TERMINATED. 

FIOS I Sfi 
FIOS. \ 5b 

READ REQUEST ON UNIT DEFINED AS SYSOU1 

ILLEGAL. 

NO OPTIONAL EXIT— EXECUTION TERMINATED 

FCNV 57 

ILLEGAL CHAR FOR L CONVERSION IN DATA 
BELOW. 

Record containing invalid character written on-line 

following message. 

Invalid character in logical input data. 

TREAT ILLEGAL CHAR AS BLANK. 

FIOU 58 

NO DOUBLE PRECISION COMPLEX ALLOWED. 
For (Ci, C 2 ) where G and/or C 2 can be single- 
precision real numbers only. 

NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 59 

NAMELIST NAME NOT FOUND OR PUNCTUA- 
TION ERROR. 

For input variable name which does not match a 
NAMELIST name, possibly due to blank invalidly 
placed in variable name or misspelling. 

NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 60 

EMBEDDED BLANKS 

For input literals containing blanks. 

NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 61 

NUMERICAL FIELD MISSING OR PUNCTUATION 
ERROR. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 62 

UNEXPECTED END OF NAMELIST OR END OF 
RECORD. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 



FIOU 63 

NAMELIST NAME NOT FOLLOWED BY MATCH- 
ING VARIABLE NAME. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 64 

SUBSCRIPTS TOO LARGE OR TOO MANY SUB- 
SCRIPTS OR INCONSISTENT DIMENSIONING. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 65 

THE SIZE OF AN ARRAY HAS BEEN EXCEEDED. 

or 
READING OF ARRAY VALUES CONTINUES. 

Literals are accepted and stored successively in 
locations following array block. 

FIOU 66 

LITERAL NOT PRECEDED BY VARIABLE NAME. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 67 

PUNCTUATION MISSING FOR COMPLEX LIT- 
ERAL. 

NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 68 

ILLEGAL CHARACTER IN LOGICAL INPUT DATA. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 69 

DATA TYPE DOES NOT MATCH VARIABLE NAME. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FIOU 70 

ILLEGAL CHARACTER OR ALL BLANKS IN LIT- 
ERAL OR VARIABLE NAME BEGINS WITH 
NUMERICAL CHARACTER. 

or 
NO OPTIONAL EXIT-EXECUTION TERMINATED. 

FCNV 71 
" INPUT DATA NOT WITHIN PERMISSIBLE RANGE 
OF FLOATING POINT NUMBERS. 

or 
READING OF INPUT DATA CONTINUES. 

FASC 72 

ARSIN(X) OR ARCOS (X), ! X j GRT THAN 1 NOT 
ALLOWED. 

For arcsin(X) or arccos(X), where | X | > 1. 

SET RESULT = 

Set arcsin(X) or arccos(X) = 0. 

FTNC 73 

TAN(X) OR COTAN(X), | X | GRT THAN OR EQ 
TO 2**20 NOT ALLOWED. 

For tan(X) or cot(X) where [ X | > 2 20 . 

SET RESULT = 

Settan(X) or cot(X) = 0. 

FTNC 74 

TAN(X) OR COTAN(X), X TOO CLOSE TO 
SINGULARITY, NOT ALLOWED. 

For tan(X) where X is near an odd multiple of -r- 
or cot(X) where X is near a multiple of ir. 

SET RESULT = + OMEGA 

Set tan(X) or cot(X) = + «. 



FSCH 75 

SINH(X) OR COSH(X), | X j GRT THAN 88.029692 
NOT ALLOWED 

* ~*Forsinh(X) = Vz (e x -e- x ) or cosh(X) = 
% (e x + e" x ) where | X | > 88.029692. 

SET RESULT = + OMEGA 

Set sinh(X) or cosh(X) = + a 

FGAM 76 

GAMMA(X), X LESS THAN OR EQ TO 2** -127 OR 
GRT THAN OR EQ TO 34.843 NOT ALLOWED. 



Forr(X) 






du where 



X < 2" 127 or X> 34.843. 
SET RESULT = +OMEGA 

Setr(X) = + «. 

FGAM 77 

ALGAMA(X), X NON POSITIVE OR GRT THAN OR 
EQ TO 2.0593*10**36 NOT ALLOWED. 



For log 



; e T(X) = j ii x_1 e -u du where 



X < or X > 2.0593(10*"). 
SET RESULT = + OMEGA 

C . 1 T/V\ — J. () 

oet luge M A / ~ ' "'• 



Added to the preceding messages, which result from 
the recognition of an fxem error condition, the follow- 
ing fptrp and fxem messages may also be written: 



FPTRP 



FXEM 



UNDRFLOW AT ***** IN AC 

or 
UNDRFLOW AT ***** IN AC AND MQ 

or 
UNDRFLOW AT ***** IN MQ 

or 
OVERFLOW AT ***** IN AC 

or 
OVERFLOW AT ***** IN AC AND MQ 

or 
OVERFLOW AT ***** IN MQ 

or 
ADDRESS AT ***** ODD 

(Note: The following table is always contained in 
the FXEM message.) 
ERROR TRACE CALLS IN REVERSE ORDER 

CALLING IFN OR ABSOLUTE 

ROUTINE LINE NO. LOCATION 

***** ****** ****** 



(After the above table, one of the following three 

items is printed.) 
ERROR CODE ***** NOT A STANDARD CODE. 

or 
A line of data containing an invalid character, if per- 
tinent to the error. 

or 
A message from the routine that called the FXEM rou- 
tine, if pertinent to the error. 

(The following item may also appear.) 

EXECUTION TERMINATED. 
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FOUT 



FBST 

FEFT 
FEFT. 



END-OF-BUFFER EXIT WRITING SYSOU1. EXE- 
CUTION TERMINATED. 

BACKSPACE REQUEST IGNORED ON UNIT**. 



REQUEST TO WRITE EOF ON UNIT ASSIGNED 
AS SYSIN1, SYSOU1, OR SYSPP1 HAS BEEN 
IGNORED. 



FRWT 
FRWT. 



FDMP 



SYSINl^SYSOUl, SPSPP1 HAS BEEN IGNORED. 
i 

EXECUTION TERMINATED BY DUMP-DISK 
ERROR. 

or 
EXECUTION TERMINATED BY DUMP-UNUSUAL 
END SYSUT4. 

or 
EXECUTION TERMINATED BY DUMP-EWA 
FLAG ON-SYSUT4. 



DMPR 



EXECUTION TERMINATED BY DUMP-LESS 

PLEASE SUPPLY CORRECT CALLING SEQUENCE 
FOR DUMP. 

or 
EXECUTION TERMINATED BY DUMP-SYSUT4 
REDUNDANCY. 

or 
EXECUTION TERMINATED BY DUMP-UNUSUAL 
END-SYSUT4. 

or 
EXECUTION TERMINATED BY DUMP-DISK 
ERROR. 

EXECUTION TERMINATED BY DUMP-EWA 
FLAG ON-SYSUT4. 

or 
EXECUTION TERMINATED BY DUMP-SYSOU1 
REDUNDANCY. 

or 
EXECUTION TERMINATED BY DUMP-UNUSUAL 
END-SYSOU1. 

or 
SYSOU1 IS NOW TAPE ON XHK/S 
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COBOL Subroutine Messages 

CBLER 

PROCESSING TERMINATED-DATA ITEM REFER- 
ENCED BEFORE ITEM IS LOCATED. 

An attempt has been made in the program to refer 
to ( 1 ) a data-item in a file that is not in OPEN 
status or (2) a data-item that follows a group de- 
fined by an OCCURS . . . DEPENDING ON data- 
name clause where data-name does not contain a 
non-zero value at the time of reference. 

CEOBP 

PROCESSING TERMINATED DUE TO TAPE 
CHECK SUM AND REDUNDANCY ERRORS. 

or 
PROCESSING TERMINATED DUE TO TAPE SE- 
QUENCE AND REDUNDANCY ERRORS. 

or 
PROCESSING TERMINATED DUE TO UNRE- 
COVERABLE TAPE REDUNDANCY ERRORS. 

or 
PROCESSING TERMINATED DUE TO TAPE 
CHECK SUM ERROR. 

or 
PROCESSING TERMINATED DUE TO TAPE SE- 
QUENCE ERROR. 

or 
PROCESSING TERMINATED DUE TO TAPE REC- 
ORD LENGTH ERROR. 

Each of the above error messages is followed by 
several lines of output of the following form: 

THIS ERROR IS ASSOCIATED WITH AN I/O VERB 
AT CARD NUMBER ******. THE FOLLOWING IN- 
FORMATION IS ASSOCIATED WITH THE FILE IN 

ERROR 

PILE NAME ****************** 

REEL SEQUENCE NUMBER ******, 



FILE SERIAL NUMBER ****** 

FILE BLOCK COUNT ****** 

After each message is written, the job is terminated 

and a full core dump is taken. 

CEXPR 

EXPONENTIAL OVERFLOW AT CARD NUMBER 

Results from accumulator oveflow caused by float- 
ing-point number which exceeds maximum value 
allowed. The largest possible floating-point num- 
ber is assumed as the result of the operation. 
Should an underflow occur, no message is written 
but the result is set to zero. 

ERROR IN EXPONENTIAL AT CARD NUMBER 

****** 

In evaluating A**B, the above message is written 
when the exponent is not valid. In particular, a 
noninteger exponent may not be used with a nega- 
tive base. 

CBDCV 

JOB TERMINATED-ENCOUNTERED INPUT REC- 
ORD LENGTH NOT A MULTIPLE OF SIX. 
JOB TERMINATED-COUNT CONTROL CONTAINS 
A NON-NUMERIC BCD CHARACTER. 

These messages are issued by CBDCV which proc- 
esses the count control word from variable length 
records. When the message is written, the count 
control word is faulty in the manner indicated. 



ACEPT 



ACCEPT FROM ****** ENCOUNTERED END OF 

TTTT TT 1 Tr?T>r\ IT IT TTTTi T>T> /~»T 7TTT>T^l-\ 

An EOF indication in the input during execution 
of an ACCEPT statement causes this message to 
be written. In the case of an ACCEPT from the 
card reader, the message results when card reader 
is empty. The area into which the data is to be 
accepted is loaded with zeros. 
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APPENDIXES 



Appendix A: Control Card Format Index 

Refer to the given page reference for a description of each card. 



CARD FORMAT 

1 3 

$* any text 



$AFTER 



lfi 



PAGE 
REFERENCE 



10 



srname 



123 



m 



*ALTER 



nl 



15 



16 



m 



*ALTER 



nl,n2 



15 



16 



$ASSIGN 



srname, ORG = nnnnn 



VZ6 



$DATA 



11 



16 



SDELETE 



srname 



123 



*DEND 



26 



16 



$DUMP n cxxxxx 



locl/loc2, loc3/loc4 

16 



59 



$EDIT 



[LOGIC] 



199. 



Appendix A: Control Card Format Index 163 



CARD FORMAT 

1 



PAGE 
REFERENCE 



*ENDAL 



15 



$ENDREEL 



11 



16 



$ENTRY 



j exname 
/ deckname 



>] 



10 



16 



$ETC 



variable field information 



37 



16 



$EXECUTE 



subsystem name 



16 



$FILE 



'filename' [,unitl, unit2] 



MOUNT 

DEFER 

READY 

or 
MOUNTi 
DEFERi 
READYi 



/ LIST 
^(NOLIST 

INPUT 
OUTPUT 
INOUT 
CHECKPOINT 

or 
CKPT 



31 



32 



'/ BLOCK ) 
lt BLK / 



= xxxx 



[,ACT = xx] 



r/ONEREEL 
(MULTIREELf 

or 
REELS 



"( NOSEARCH n 
^SEARCH /J 



32 



*- I IUGIV 

i LOW 

200 

.556 

800 



r/BCD \nr/SLABEL \ n 



I BIN 

|MXBCD 

MXBIN 



HILABEL 
' LOLABELf 
FLABEL 



33 
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CARD FORMAT 



PAGE 
REFERENCE 



NOSEQ 
jSEQ 
or 
SEQUENCE 



j NQCKSUM ) 

_;\cksum /_ 



j NOCKPTS ) 
_'\ CKPTS / _ 



33 



r/SCRATCH\ 



[,AFTERLABEL] 



PRINT 
) PUNCH 

_(hold )_ 



-( CYLINDER \ ( 
JCYL ° r j 



XXX 



33 



(CYLCOUNT) 
_\ CYLCT / 



xx 

XXX 



r wm r nrr , m 



16 



r ( HNRNFP 

JHRFP 

' HRNFP 

(hnrfp 



34 



SGROUP 



'filenamei', . . . 'filename n ' 
[,OPNCT = xx] [,BUFCT = xxx] 



35 



16 



&TRCRC HfinlcnflmR 



-( NQLIST )n 

/ T 1ST I 



r; 



NOREF 



V 



L(fulist)J^ w U 



[ { NODECK j _ 



19 



•(M90 V 
1 M94 \ 
.(M94/2). 



[{IS}] 



" ( INLINE 
' 1 TIGHT 



j IQEND VI 
l\ READON /J 



"( COMSEQ ) 
;\BINSEQ {_ 



' ( NODD V 

it DD ). 



16 



$IRDBL 



;,TRAP MAX = ni ] [,LINE MAX=n 2 ] [,NOMESj 



25 



16 



$IRDRC 



[name] 



location [, FATAL] 25 
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CARD FORMAT 

1 8 



PAGE 
REFERENCE 



16 



$IBFTC 



deckname 



■( NOUST V 
/LIST I 

_(fulist )_ 



J DECK 

Inodeck 



-(M90 
JM94 

M94/2 



17 



t{S}] 



-( NODD )- 
, DD 
_(SDD ) 



16 



$IBJOB 



(GO I 
^|NOGO/_ 



"(NOLOGICr 
J LOGIC \ 
_(DLOGIC ) 



•J NOMAP V 

;|map / 



/NOFILES 
j \ FILES 



/ SOURCE VI 
'_{ NOSOURCE /J 



IOEX 

MINIMUM 
I BASIC 
(LABELS 

'fiocs 

ALTIO 



I FLOW | 
l\ NOFLOW /_ 



16 



$IBLDR 



deckname 



-j NOLIBE 

'1 LIBE 



" j TEXT 
*(NOTEXT/_ 



31 



l 



7-72 



16 



$IBMAP deckname 



[, count] 



"(LIST VI f/REF VI r/DECK \1 
;|NOLIST/J QNOREF/J QNODECK/_ 



22 



-( NOSYM )-] r(M9Q ) 
JmONSYMV >/M94 J 
_(JOBSYM jj L(M94/2)_ 



T/NO ( 

\l\TT 



OK 



}][{ 



NOMFTC 1 
MFTC /_ 



"( RELMOD )n 
JSYSMOD I 
ABSMOD 



-( NODD )-l 

, DD 

_ ( SDD ) 



$IBREL 



11 



$IBSYS 



10 



$ID 

166 



any text 



10 



CARD FORMAT 

1 



$IEDIT 



PAGE 
REFERENCE 



16 



rf NOSRCH 



r/sYsiNi n J g^- f HNQALT 

QSYSxxx U \^ S *™1 jj QALTER 



"iNOALTER 



12 



$INCLUDE 



$INSERT 



$JOR 



$LABEL 



16 



I exname J 

1 deckname j'"' 



16 



[srname] [, ORG=nnnnn] 



16 



any text 
16 



'file name', 



— / serial 
or 
home 
address 



LreelJ 



r C date \ ~ 
L ( days f _ 



,Lnamej 



42 



123 



34 



$NAME 



deckname ( exname ) = exname, . . . 
exname = exname 

'deckname ( filename )' = 'filename', . 
'filename' = 'filename', . . . 



JJ 



36 



$OEDIT 



$OMIT 



$ORIGIN 



$PATCH 



cxxxxx 



16 



r/ SYSOUi n r/ NOPREST n T/NOCPR \~\ 
QSYSxxx J J QPREST )\ QCPREST/J 



16 



jexname 

{deckname (exname), 



16 



logical ["absolute - ! r/ SYSUT2 )"| f/NOREWn 
origin |>igin J [\SYSxxx )] |_IREW /J 



16 



instr. 1, instr. 2, 



13 



36 



41 



60 
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CARD FORMAT 

1 



$PAUSE 



$POOL 



$POST 



$REPLACE 



$SIZE 



PAGE 
REFERENCE 



16 



instructions to operator 



10 



16 



'filename!', . . . 'filename,/ »< fiLK I = xxxx | [, BUFCT = xxx] 



16 



srname [, ORG = nnnnn] 

16 



/ / = n 



35 



11 



122 



36 



$STOP 



$TITLE 



$USE 



[NODAT] 



16 



any text 

16 



deckname (exname), . . . 



10 



11 



36 
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Appendix B: Control Card Check List 



SOURCE LANGUAGE PROGRAMS 



$JOB 


X 


$ID 





$EXECUTE 


X 


$*. - 





&PAUSE 





$STOP 





$IBSYS 





$IBJOB 


X 


$ENDREEL 





$DATA 


o 


$IBREL 






$TITLE 



$FILE 



RELOCATABLE 

BINARY 

PROGRAMS 



COMMENTS 

One required at the beginning of each job. 

Transfers control to installation accounting routine. 

Causes the loading of the Processor Monitor. 

Comments card. 

Permits operator action. 

Transfers control to the System Monitor for processing. 

Next job segment will not be processed by the IBJOB Processor; 

control is transferred to the System Monitor. 

Initiates an IBJOB Processor application; one required for each 

Processor application. 

Causes a reel switch involving SYSIN1 and SYSIN2. 

Indicates the beginning of a data file. 

Indicates that the decks that follow do not need compiling or 

assembling. 

Causes the information in columns 16-72 to be printed on the 

next Processor or Assembler listing output. 



ATDrvrn 

qubr ivj 










r> 1 — u rnpTpiM A^V 




A 






$IBCBC 


X 








Precedes each COBOL deck. 


$CBEND 


X 








Follows each COBOL deck. 


$IBMAP 






X 




Precedes each MAP deck. 


$IBLDR 








X 


Precedes each relocatable program to be loaded. 


SENTRY 








o 





Specifies the location to which the initial transfer to the object 
program will be made. 


$IEDIT 





o 


o 


o 


Sets input specifications other than standard. 


$OEDIT 


o 


o 


o 


o 


Sets output specifications other than standard. 



$LABEL 


O 


o 








$POOL 





Q 





Q 


$GROUP 





o 








$NAME 


o 


o 





o 


$USE 


o 








o 


$OMIT 


o 


o 


o 


o 


$SIZE 

<ttT"T , / r -' 


o 


o 


o 


o 



Provides file specification; supersedes some assembled specifi- 
cations. 

Provides label information for files. 
Designates files to share common buffer areas. 
Designates how buffers are to be shared by a group of files. 
Used to change control section names of file names. 
Specifies that a particular control section is to be used. 
Specifies that a particular control section is to be deleted. 
Specifies the size of Blank COMMON. 



JAIC11UO 



•fcTTTT vr <fcpr»rvr <tOTjr»TTP 



$USE, $OMIT, $NAME, or $ETC card. 



$ORIGIN 
$INCLUDE 



Used to define the structure of an overlay deck. 

Specifies the decks or control sections to be included in a link. 



$AFTER 


o 











$ASSIGN 


o 











$DELETE 














$EDIT 
$INSERT 


o 
o 


o 
o 




o 






$REPLACE 


o 











$IBDBC 


X 








$IBDBL 
*DEND 
$POST 






o 







o 




o 
o 
o 



Causes the Librarian to copy the Library from its current posi- 
tion through the named subroutine. 

Causes the Librarian to copy the current Library up to, but 
not including, the named subroutine. 

Causes the Librarian to copy the Library from its current posi- 
tion up to, but not including, the named subroutine. 
Causes the Librarian to be called for an editing run. 
Causes the Librarian to place the subroutine deck that follows 
the card into the Library at the current position of the Library 
file. 
Permits a subroutine in the Subroutine Library to be replaced. 



Precedes each compile-time debugging request and defines the 

point where the request is to be executed. 

Precedes each load-time debugging request packet. 

Terminates the load-time debugging package. 

Causes the load-time debugging postprocessor routines to be 

called. 



♦ALTER 
*ENDAL 



Used to alter a source, symbolic, or Prest deck. 
Required to end an alter deck. 



SDUMP 
$PATCH 



Causes portions of system records to be dumped. 
Used to insert temporary patches in system records. 



Notation: x— necessary; o— optional; blank— does not apply. 
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Appendix C: IBJOB Communication Region 



The components of the ibjob Processor System transfer 
control and information to each other and to the ibsys 
system through specified words in the ibjob commu- 
nication region. These words are: 

LOCATION RELATIVE TO OCTAL 

SYMBOL COMMUNICATION REGION BASE LOCATION 

SYSLOC IBJCOM 21234 

SYSFAZ IBJCOM + 1 21235 

IBJCOR IBJCOM +2 21236 

IBJDAT IBJCOM + 3 21237 

JLDAT IBJCOM +4 21240 

•JTYPE IBJCOM + 6 21242 

JLIN IBJCOM + 7 21243 

JVER IBJCOM + 8 21244 

JKAPU IBJCOM + 9 21245 

SYSDSB IBJCOM + 10 21246 

■FDPOS IBJCOM + 12 21250 

SSTRA IBJCOM + 15 21253 

ACTION IBJCOM + 16 21254 

JOBIN IBJCOM + 17 21255 

JOBOU IBJCOM + 18 21256 

JOBPP IBJCOM + 19 21257 

IOEDIT IB T COM + 20 21260 

JREEL IBJCOM + 21 21261 

SUBSP IBJCOM + 22 21262 

PUNCH IBJCOM +23 21263 

SYSSHD IBJCOM + 24 21264 

LILDMP IBJCOM +25 21265 

IBSLB IBJCOM + 26 21266 

PRSW IBJCOM + 27 21267 

JLNSIZ IBJCOM + 28 21270 

INPOP IBJCOM + 29 21271 

SUBSYS SUBSYS 21412 

DEFINE IOCS 21347 

JOIN IOCS + 2 21351 

ATTACH IOCS + 4 21353 

CLOSE IOCS + 6 21355 

OPEN IOCS + 8 21357 

READ IOCS + 10 21361 

WRITE IOCS + 12 21363 

STASH IOCS + 14 21365 

The contents of some of the more important ibjob 
communication region locations are described in the 
following two lists. The first list contains locations 
available only up until execution of object programs. 
The octal address of the location is given in column 1. 
Column 2 gives the symbolic name of the location. 
The third column provides information regarding the 
use of the location. 



OCTAL SYMBOLIC 

LOCATION NAME 

21263 PUNCH 



REMARKS 

Set to nonzero by IBMAP if 
NODECK option is requested 
by a compilation or an assem- 
bly. This location is tested by 
the JOBPP punching routine 
in the IBJOB Monitor. It is 
set to zero if a punched deck 
is wanted. 



OCTAL SYMBOLIC 

LOCATION NAME 

21264 SYSSHD 
( System 
subhead ) 



21267 



21272 



21273 



21301 



21315 



21323 



PRSW 
(Print 
switch ) 



COMCEL 

( Communication 
word) 



EOFPP 

( End of file on 

peripheral 

punch ) 



Set by a subsystem under the 
IBJOB Monitor. Contains the 
location and length of a sub- 
heading to be used in the 
listing. 

Set to nonzero on the distrib- 
uted IBJOB system tape. It 
may be changed at an instal- 
lation. If the location has a 
value of zero, most IBJOB 
Monitor messages will occur 
on-line as well as off-line. If 
the location has a nonzero 
value, on-line printing of 
IBJOB messages is minimized. 

Set and used by the IBJOB 
Monitor. Contains flag bits re- 
lating to control card options, 
input/output editor uses, load- 
ing, execution, and other 
functional operations. 

Set to nonzero on the distrib- 
uted IBJOB system tape. It 
may be changed at an instal- 
lation. If the location has 
nonzero value, end-of-file mark 
is put on the peripheral punch 
tape at the end of each Proc- 
essor application (that is, the 
job is contained between a 
$IBJOB card and the next end 
of file, including the DATA 
file if any). If the value is 
zero, no end-of-file mark is put 
on the peripheral punch tape. 

Contains the current deck 
name from columns 8-13 of 
the last deck control card ( for 
example, $IBLDR, or$IBFTC) 
encountered by IBJOB. 

Contains job name from col- 
umns 8-13 of last $IBJOB 
control card. 

Determines type of output to 
be generated. When the loca- 
tion has a value of zero, out- 
put is in BCD mode, with 
blocking of up to five lines 
per block. When the location 
has a nonzero value, output is 
in binary mode, with block- 
ing of up to five lines per 
block. This output can be 
printed off-line. 

The second list of IBJOB communication words con- 
tains locations available both before and after object 
program loading. In this table, column 1 contains the 
octal address of the location only up until execution. 



DECK 



JBNAM 

( Job name ) 

TYPOU 

( Type of 
output ) 
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Column 2 gives the symbolic name of the location. In 
two cases the symbolic name is different after loading. 
These changes are given in parentheses. 



OCTAL SYMBOLIC 

LOCATION NAME 

21234 SYSLOC 



21235 SYSFAZ 



21236 IBJCOR(JOR; 



21237 IBJDAT 
(JDATE) 



21240 JLDAT 
21241 



Contains the complemented 
location of last MAP language 
CALL pseudo-operation that 
has been executed. 

Contains record name of last 
system read. At execution 
time, this location contains 
.OB T PR. 

Contains upper and lower 
limits of core storage currently 
available to IBJOB. 

Contains the date appearing 
in the IBSYS date location 
SYSDAT. Format is YY DDD, 
where YY is year and DDD is 
day of year. 

Contains same date as 
IBJDAT but in form MM/ 



OCTAL SYMBOLIC 

LOCATION NAME 

91949 TTYPK 



21243 JLIN 

21244 JVER 
21246 SYSDSB 

21250 .FDPOS 



and DD is day of month. 



REMARKS 

Contains zero if s v stem is on 
7090 and nonzero if it is on 
7094. 

Contains count of lines output 
on SYSOU during current 
Processor application. 
Contains version number of 
IBJOB system in the form: 
BCI l,VERxxx 

Contains an enable instruction 
from a location containing 
zero and is used by a varia- 
tion of the SAVE pseudo- 
operation to disable traps. 
Contains location of FOR- 
TRAN dump record. Prefix is 
device type (PZE for 729, 
MZE for 1301, or PTW for 
7340). Tag is SYSUNI index 
for the unit. If record is on 
tape decrement and address 
are file and record positions. 
If record is disk, address is 
track address and there is no 
decrement. 
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Appendix D: Sample Control Card Deck 



|$IBJOB GO 

[$EXECUTE IBJO B" 

JSJOB \ 

| End of File Card \ U 





[ (FORTRAN Deck) 
|$IBFTC DECK1 
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Appendix E: Procedure for Selecting the 7094 Optional Conversion Routine 



A new release procedure provided with Version 5 of 
the Subroutine Library permits the 7094 customer to 
select the optional conversion routine ( fcnv ) . 

Both the standard conversion routine and the op- 
tional conversion routine are on the released svmbolic 
tape. The standard conversion routine is automatically 
provided when creating a system tape, unless other- 
wise specified by the customer. 

In order to specify the optional conversion routine, 
the following three cards must be included in the 
special deck for 7094 iblib assembly used to create the 
new 7094 system tape. The format of these cards is: 



1 


8 


16 


72 


\ tr\r\r\ a 


CT?T 

on, a 


94 


OlOWl/W 


M9094 


SET 


94 


3F4C0015 


M9094 


SET 


94 


3F4M0015 



The inclusion of these three cards causes the optional 
conversion routine fcnv, as well as modified versions 
of the routines fioh and fwro, to be selected from the 
symbolic tape. 

Note: The 7090/7094 user will receive another deck 
(called the 7090 Asterisk Deck) which will generate 
asterisks if an insufficient field width is specified in a 
program using the standard 7090 conversion routines. 
Output through the standard 7090/7094 conversion 
routines will thus be made consistent with output from 
the 7094 optional conversion routine. Appendix H 
contains instructions on how to use the 7090 Asterisk 
Deck. 
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Appendix F: Core Storage Load Map 









* MEMORY 


MAP * 
























SYSTEM 






00000 


THRU 02717 




















FILE 


BLOCK ORIGIN 




02720 
























FILES 1 


INFILE 




























2 


OUFILE 


























FILE 


LIST ORIGIN 




02750 
























PRE- 


EXECUTION INITIALIZATION 


02754 
























CALL 


ON OBJECT PROGRAM 




02777 
























OBJECT PROGRAM 




03004 


THRU 12573 




















LINK 


DECK 


ORIGIN 


CONTROL 


SECTIONS 


(/NAME/ 


= NON 


LENGTH, (LOC)=DELETED, *=NOT 


referenced; 


1 







DECKA 


03004 


H 
G 


03051 
03154 


CONSTA 


03140 




CONSTB 


03141 




CONSTC 


03142 




CONSTD 


03143 




.LINK 


03173 


/.LDT / 


03173 /.LRECT/ 


03177 




/.LVEC / 


03205 
















.LXCON 


03217 


.LXSTR 


03217 


•LXSTP 


03223 




.LXOUT 


03271 


* 


.LXRTN 


03303 




IBEXIT 


03303 








.LXCAL 


03306 * 


•LXERR 


03306 




.DBCLS 


03501 


» 


.LXARG 


03650 


» 


.LO 


03673 








.CLSE 


03701 


• LFBL 


03702 


* 


.LUNB 


03703 




-OFOUT 


03704 










.IODEF 


03710 


.DEFIN 


03710 


.ATTAC 


03714 


* 


•CLOSE 


03716 




.OPEN 


03720 




.READ 


03722 








•WRITE 


03724 


• BSR 


03734 


* 


•READR 


03744 




•RELES 


03746 


* 


.LAREA 


03757 








.LFBLK 


03775 


• LTSX 


04000 


* 


.AREA1 


04012 




.LUNBL 


04020 




.ENTRY 


04024 








.GOA 


04055 


.GO 


04061 




• DERR 


04075 




.NOPXI 


04076 




•COMXI 


04100 








• EX34 


04122 


























.LOVRY 


04127 


.LOVRY 


(04127) 


.LDT 


(03173) 




.LRECT 


(03177) 




• LVEC 


(03205) 










• L X S L 


04506 


•LXSEL 
.LXDIS 


04506 
04641 


-LXTST 
.LXFLG 


04521 
04642 


* 


•LXOVL 
.LTCH 


04561 
04643 


* 


.LXRCT 


04567 


• 


.LXIND 


04636 




.FPTRP 


04650 


.FFPT. 


04650 * 


•FPOUT 


04777 


« 


.FPARG 


05C05 


* 


/.COUNT/ 


05007 


* 


OVFLOW 


05053 




XIT 


0506C 


EXIT 


05060 


.EXIT. 


05060 


* 




















FXEM 


05061 


.FXEM. 


05061 


.FXOUT 


05411 


* 


.FXARG 


05417 


# 


/.OPTW./ 


05473 


• 








FDMP 


05504 


DUMP 


05504 


POUMP 


05506 


* 




















.IOCS 


06742 


• L<0) 


06742 


•MONSW 


06762 




.TEOR 


07031 




.DEFI. 


07111 




.JOINX 


07155 








.CLOS. 


07174 


•ATTC. 


07207 




• SHI 


07421 


* 


• SH9 


07463 


* 


.OPEN. 


07504 








.0P4 


07532 * 


• 0P7 


07563 


* 


.0P9.2 


07577 


•» 


.RLSE. 


07643 




.RER2. 


07643 








.READ. 


07644 


•RER1. 


07667 




.WRIT. 


07671 




•MNT1A 


10057 


* 


.EOFBX 


10140 








.FEEIT 


10210 


.GTIOX 


10231 




.RW7 


10347 


* 


.RE7 


10766 


* 


.ENCTR 


11427 








•SEL59 


11431 • 


.BSR. 


12042 




•EOTOF 


12165 




.ET0F3 


12173 


* 


.SWITC 


12222 








-TCHEX 


12523 


.BASIO 


12526 


• 




















.IOCSM 


12527 




























1 


DECK1 


12527 


/RTNEA / 


12527 
























2 


DECK2 


12527 


/RTNEB / 


12527 /RTNEC / 


12547 






















DECK3 


12555 


/RTNED / 


12555 
























3 


DECK4 


12565 


/RTNEE / 


12565 
























I/O BUFFERS 






12574 


THRU 77765 




















UNUSED CORE 






77766 


THRU 77777 





















A load map of core storage prior to object program 
execution is generated by the Loader in response to 
the map option punched on a $ibjob card. In the 
"System" section of the load map are contained those 
parts of the ibsys Monitor, iocs, and ioex needed for 
job-to-job operation. "File Block Origin" refers to 12- 
word working file blocks, one block for each file named 
in the program. The "File List" contains two-word 
entries, one entry for each file. The contents of the "Pre- 
Execution Initialization" section of the load map are 
described in the "Loader Information" section of this 
manual under "Control of Program Execution." The 
call on the object program is also described there. 
The object program itself consists of the instructions 
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as generated by the Assembler or the Fortran iv Com- 
piler supplemented by subroutines loaded from the 
Subroutine Library. In the load map shown, the sub- 
routine names begin with .link. The column entitled 
"link" refers to overlay links. 

The control sections in each deck are listed in rows 
of five. The names of the control sections with lengths 
greater than zero are bounded by slashes. The names 
of control sections that are not referred to during 
execution are followed by asterisks. A deleted control 
section would appear as follows: 

CONSTA (02763) 
An expanded even control section would appear 
as follows: 

EVEN 02763 CONSTA 02764 
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The following machine configuration is required for 
the operation of the ibjob Processor: 

An ibm 7090 or 7094 Data Processing System 

An ibm 716 Printer 

An ibm 711 Card Reader 

Required for Installations Using Only IBM 729 (II, 
IV, V, or VI) Magnetic Tape Units and/or IBM 7340 
Hypertape Drives: Eight units are required ordinarily. 
If an ibm 1401 with its attached ibm 1402 Card Read 
Punch and ibm 1403 Printer is available for processing 
system output, and a single tape unit is assigned by 
the System Monitor to both sysoui and sysppi (list and 
punch functions ) , only seven units are required. When 
load-time debugging is used, an additional unit is 
necessary, attached as sysck2. 



Required for Installations using IBM 1301/2302 Disk 
Storage or IBM 7320 Drum Storage: Four tape units 
are required ordinarily, ibm 729 Magnetic Tape Units 
or ibm 7340 Hypertape Drives can be assigned in any 
combination. If an ibm 1401 with its attached card 
read punch and printer is available for processing 
system output and a single tape unit is assigned by 
the System Monitor to both sysoui and sysppi (list 
and punch functions ) , only three units are required. 

Five other units are required ordinarily, ibm 729 
Magnetic Tape Units, ibm 7340 Hypertape Drives or 
selected cylinders of ibm 1301/2302 Disk Storage or of 
ibm 7320 Drum Storage can be assigned to the installa- 
tion in any combination. When load-time debugging is 
used, an additional unit is necessary, attached as sysck2. 
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Appendix H: FORTRAN IV Mathematics Subroutines- 
Algorithms, Accuracy, and Speeds 



This appendix presents the algorithms, statistics on accuracy, and average speed 
for most of the Fortran iv mathematics subroutines. 

Algorithms 

Some of the formulas are widely known; those that are not widely known are de- 
rived from more commonly known formulas. The steps leading from the common 
formulas have been detailed so that derivation can be reconstructed by anyone 
who has a basic understanding of mathematics and who has access to the common 
texts on numerical analysis. Background information for algorithms involving 
continued fractions may be found in the publication entitled Analytic Theory of 
Continued Fractions, written by H. S. Wall and published in 1948 by the D. Van 
Nostrand Co., Inc., of Princeton, N. J. 

Accuracy 

Because the size of a machine word is limited, small errors may be generated by 
mathematical subroutines. In an elaborate computation, slight inaccuracies can 
accumulate to become larger errors. Thus, in interpreting final results, the user 
should take into account any errors introduced during the various intermediate 
stages. 

The accuracy of an answer by a subroutine is influenced by two factors: ( 1 ) the 
accuracy of the argument and (2) the performance of the subroutine. 

Accuracy of the Argument 

Most arguments contain errors. An error in a given argument may have accumu- 
lated over several steps prior to the use of the subroutine. Even data fresh from 
input conversion contain slight errors since decimal data cannot usually be exactly 
converted into the binary form required by the processing unit; the conversion 
process is usually only approximate. Argument errors always influence the accuracy 
of answers. The effect of an argument error on the accuracy of an answer depends 
solely on the nature of the mathematical function involved and not on the par- 
ticular coding by which that function is computed within a subroutine. In order 
to assist users in assessing the accumulation of errors, a guide on the propagational 
effect of argument errors is provided for each function. Wherever possible, this 
is expressed as a simple formula. 

Performance of the Subroutine 

The performance statistics supplied in this appendix are based upon the assump- 
tion that arguments are perfect (i.e., without errors, and therefore have no argu- 
ment error propagation effect upon answers). Thus, the only errors in answers 
are those introduced by the subroutines themselves. 

For each subroutine, accuracy figures are given for one or more segments 
throughout the valid argument range(s). The particular statistics given are those 
most meaningful to the function and range under consideration. For example, the 
maximum relative error and standard deviation of the relative error of a set of 
answers are generally useful and revealing statistics, but useless for the range of a 
function where its value becomes 0, since the slightest error of the argument value 
can cause an unbounded fluctuation on the relative magnitude of the answer. Such 
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is the case with sin(x) for x near v, and in this range it is more appropriate to dis- 
cuss absolute errors. 

Symbols Used in Describing Accuracy 

In the presentation of error statistics, the following symbols are employed: 

g(x) = the answer given by the subroutine for the mathematical function under 

discussion 
f(x) = the correct extra-precision answer for the mathematical function under 

discussion 



ri v i rn i" i 



f(x) 
8 = the relative error of the argument 



the relative error of the answer 



E 



f(x) — g(x) , the absolute error of the answer 



A = the absolute error of the argument 



M(E) = Max 



f(*)-g(*) 



during testing 

M(.) =Maxl f W~gW 
I f(x) 

during testing 



, the maximum absolute error produced 
, the maximum relative error produced 



" (e) = v^2, ! fw-gw 

(standard deviation) absolute error 



the root-mean-square 



a(e) = l-A-V ' f ^"^ 



\ N Xi 



2 , the root-mean-square 



f(*i) 
( standard deviation ) relative error 

When applied to complex numbers, the absolute value signs in the above for- 
mulas should be regarded as denoting complex absolute value. Thus, the above 
formula for E represents the vector error when applied to a complex function. 



Algorithms, Accuracy, and Speeds 

The algorithms and performance statistics for most of the Fortran iv mathematics 
subroutines are shown in the following section. The subroutines appear in the 
same order as in Figures 25A, 25B, 25C, and 26. The subroutines not described are 

FXPl, FXP2, FXP3, FDXl, FDX2, and FDMD. 

Single-Precision Subroutines 

The following information describes single-precision subroutines listed in Fig- 
ure 25A. 

Square Root — FSQR 

Algorithm 
1. Write 

x = (2 2 P-*)m, where p is an integer, q = or 1, and Vz < m < 1. 
Then 



V* = 2*V(2- <1 )m, where Y4 < (2-*)m < 1. 
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2. Take the first approximation y to be 
t/o = 2* (-|- + y 2 \if<7 = 0,and 

Vo = 2P (^-+y 4 ),if<7 = l. 

The relative error of this approximation is less than 2 -4 . 

3. Apply the Newton-Raphson iteration 3 times to y as follows: 

ih + . -*(».+■£■)• 

Using the rule e rt+ i ~ ^ e n 2 , the relative error of j/3 is down to 2 -39 . 
Effect of Argument Error 

Performance Statistics 

Performance statistics for the single-precision square root subroutine are as 
follows: 



Argument 
Range 


Root-Mea n-Sq ua re 

Relative Error 

,(E) 


Maximum 

Relative Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


x>io- 80 


3.09 X 10"° 


7.25 x io -9 


238 


149 


Accuracy is the same for arguments less than TO -80 , but speed is slower because of floating-point underflow. 



The sample arguments upon which these performance statistics are based were 
exponentially distributed over the specified range. 

Exponential — FXPF 
Algorithm: 

1. Write 

x [log 2 (e)] = n + r, where n is the integer part and r is the fraction part. 

Then 

e x = (2 n ) (2 r ), where -1 < r < 1. 

2. Compute 2 r by the means of a rational approximation formula where — 1 < 
r < 1. This formula was derived in the following way. Take the Gaussian con- 
tinued fraction 

3__1_J5__Z__Z_ Z Z Z Z Z 

6 ~ 1-1 + 2-3 + 2-5 + 2-7 + 2-..., 
truncate at the ninth term and rewrite to obtain 

gsat 1680 + 840z + IgOz 2 + 20z 3 + z 4 
6 - 1680 - 840z + 180z 2 - 20z 3 + z i 
Substituting r [log e (2)] f or z and rewriting the above, we get 

2r 

, where A, B, C, and D are constants. 



2'=1 + 



cr 



2 _ 



r + D - 



B 



r 2 + A 
The maximum relative error of this formula is 1.6 X 10 -9 . 

3. If x < -89.415987, is given as the answer. 

4. The computation is carried out in fixed-point to minimize truncation errors. 

Effect of Argument Error 

c ~ A. Since A = 8 • x, for the larger value of x, even the round-off error of the 
argument causes a substantial relative error in the answer. 
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Performance Statistics 

Performance statistics for the single-precision exponential subroutine are as 
follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 

<r(e) 


Maximum 

Relative Error 

M (e) 


Average Speed in 
Microseconds 


7090 


7094 


0<X<1 


3.36 X 10 -9 


7.32 x i<r B 


288 


188 


-88.028<X<88.028 


4.80 X 10"" 


1.50 X 10" s 


288 


188 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 

Logarithm — FLOG 

Algorithm 

1. If j 1 — x|<2 -7 , use the polynomial approximation 

log (1 + z) = z - [2- 1 + 3 (2- 18 )] z 2 + Vs 23 , where z = x - 1. 
The maximum relative error of this formula for | z | < 2 -7 is 3 X 10 -8 . 

2. If | 1 — x | > 2 -7 , reduce the case as follows: 
Write 

x = (2 p ) m, where Vi < m < 1 and z = Im - —7= \ I I m + ~7%) ■ 
Then 

I 2 I < 0.1716. 
Also 

1 + 2 



1-2 

And 



.(v.) 



m. 



loge* = r p - Vz + log 2 ( Z V\ log e 2. 



3. By transforming the Taylor series into a continued fraction ( see Wall's Ana- 
lytic Theory of Continued Fractions, page 196 ) , we obtain 



log 6 



m) 



= 22 



1 + y 3 2 2 + 



- — + 2- 2 + W(Z) 

7 



Replacing the remainder term w(z) with its approximate value of 

_ 11 f 

(7 )(9)(140) t0r 

2 = p *£.„ , we obtain the approximation 

w /l + 2\ (3 3 )(4)(5)(7 2 ) - (3)(3371)(2 2 ) - (1019)(2 4 ) 
l0ge \l-z)= (3 3 )(4)(5)(7 2 ) - (3)(6311)(2 2 ) K ^ } ' K ' 

This reduces to the form 

log, (t=t) « « [c + ^ + ^fz} 

The maximum relative error of the formula ( * ) is 0.62 X 10~ 9 for | 2 | < 0.1716. 
However, since the procedure in item 2 above may involve cancellation of signifi- 
cant digits, this relative accuracy cannot be maintained for the final result if the 
argument is near 1. 
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Effect of Argument Error 

E ~ 8. In particular, if 8 is the round-off error of the argument, say 8 ~ 7 • 10~ 9 , 

then E ~ 7 • 10 -9 . This means that if the argument is close to 1, the relative error 

can be very large, since the function value is very small. 

Performance Statistics 

Performance statistics for the natural logarithm function of the single-precision 

logarithm subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 
Absolute Error 

.(E) 


Maximum 
Absolute Error 

M (E) 


Average Speed in 
Microseconds 


7090 


7094 


%<x<% 


1.18 X 2 -33 


1.20 X 2 -31 


361 


208 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 



Argument 
Range 


Root-Mean-Square 
Relative Error 

<r(E) 


Maximum 
Relative Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


All positive numbers 
outside (%, %) 


3.21 X 10 -8 


7.24 X 10 _0 


390 


226 



The sample arguments on which the above statistics are based were exponentially 
distributed over the specified range. 

Performance statistics for the common logarithm function of the single-precision 
logarithm subroutine are as follows : 



Argument 
Range 


Root-Mean-Square 
Absolure Error 

<r(E) 


Maximum 

Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


%<*<% 


1.95 X 2 -34 


1.03 X 2" 31 


405 


234 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 



Argument 
Range 


Root-Mea n-Sq ua re 
Relative Error 


Maximum 

Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


All positive numbers 
outside %, % 


4.70 X 10 -9 


1.57 X 10" s 


434 


252 



The sample arguments upon which the above statistics are based were expo- 
nentially distributed over the specified range. 

Sine/Cosine — FSCN 

Algorithm 

1. sin(-x) = -sin(x),cos(—x) = cos ( x ). Assume x > 0. 

2. Write 

* = -^-(q) + r, where q is an integer and < r < — . Let q = q [mod 8]. 

4 4 

3. If cos (x) is desired, raise q by 2, reduce it modulo 8 and compute sine. If 
sin(x) is desired and if x < 2 Vi , give x as the answer. 

4. Now the case is reduced to the computation of sin ( — q + r J , 
where < q < 7. ■ - 
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r ~ 



Using the formulas 

r _ i . ... . 

sin I —(4 + </ ) + r I = - sinl -^-q + r L where < q < 3 

sin rL + r = cos — — r 
L4 J _4 J 

sin — + r = cos(r) 

sin ^ +f J = sin [^-r], 

the ease is reduced to the computation of sin ( r ) or cos ( r ) f or < r < — - . 

5. The coefficients of approximation 
sin(r) = r(s + s x r 2 + s 2 r 4 + s 3 r 6 ) 

7T 

were obtained by the Chebyshev interpolation over the range < r < — -. 

The coefficients of approximation 

cos(r ) = 1 + c-j 2 + 02^ + Czt® + c±r 8 

were obtained by the Chebyshev interpolation over the range —0.01 < r < — . 

The relative error of the sine formula is less than 0.34 X 10 ~ 8 . The relative error 
of the cosine formula is less than 0.73 X 10 -10 . 

6. The computations are carried out in fixed-point to minimize truncation errors. 

Effect of Argument Error 

E ~ A. As the argument gets larger, A grows, and since the function value is peri- 
odically diminishing, no consistent relative error control can be maintained outside 

the principal range ( — -y- , -y- J. This holds true for the cosine functions as well. 

Performance Statistics 

Performance statistics for the sine function of the single-precision sine/cosine sub- 
routine are as follows : 



Argument 
Range 


Root-Mean-Square 
Absolute Error 

cr(E) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


lxl< — 


1.12X2" 29 


1.00X2 -27 


381 


240 


-y<ixi<io 


1.51 X2 -29 


1.65X2' 27 


418 


260 


10<lxl<100 


1.50X2" 29 


1.69X2' 27 


415 


258 



Argument 
Range 


Root-Mea n-Sq ua re 

Relative Error 

(Tie) 


Maximum 

Relative Error 

M ( C ) 


Average Speed in 
Microseconds 


7090 


7094 


lxl<— 


3.65 xi or* 


1.34X10 -8 


381 


240 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 
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The performance statistics for the cosine function of the sine/cosine subroutine 
are as follows : 



Argument 
Range 


Root-Mean-Square 
Absolute Error 

*( E ) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


O^X^TT 


7.56 X2- 28 


1.72X2" 27 


429 


267 


-20^x^0, 

7T^X^20 


1.53 X2~ 29 


1.60X2 27 


430 


266 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 

Tangent /Cotangent — FTNC 

Algorithm 

1. If x < 0, use 

tan (x) = —tan (x), 
cot ( — x ) = — cot ( x ) . 

Assume x > now. 

2. Write 

x = — q + r, where q is an integer and < r < -^- . 

Let qo = q [mod 4]. 

3. If q = or 2 (i.e., octant 1 and 3), define r = r.~ 

If q = 1 or 3 (i.e., octant 2 and 4), define r = -^ r. 

4. Define the case number s as follows : 
If tan(x) is desired, 

s = q . 

If cot (x) is desired, 

5 = 1, if q = 0, 
s = 0, if q = 1, 
s = 3, if q = 2, 
s = 2,if</o = 3. 

5. Compute the factor F as follows : 

,, , , 13.946 r 2 ~ 313.11 ., n 1A 

F = 1 + , if r > 2- 14 . 



r 2 ~ 104.46 + 
F = 1, ifr <2- 14 . 



939.3 3 
n> 2 



This approximation can be obtained by rewriting the continued fraction 
tan(r ) _ 1 r 2 r 2 r 2 r 2 



n 1-3-5-7- 8.946 

The maximum relative error of this formula is 10~°. 

6. Now the answer is -jj- for s = 0, — for s = 1, - — for s = 2 and 

F fo r 

F 
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Relative Error Control 

t gtv - t Qn\vyt t£ $\t* ^a.ss number p above is 1 or 2 and if the reduced argument 
r is less than 2~ 26 +" (with the exception of cotangent entry with small argu- 
ments), an execution error is signaled. In such a case, when the argument is so 
close to a singularity that the minimal indeterminary of the argument (due to 
prerounding) can cause a relative error of up to Vz. No screening is given for 
arguments near a zero of the function. 

Control can be strengthened or eliminated by the use of the subroutine fmtn. 

If j x j ^ 2 20 or if cotangent is asked with | x [ < 2 -120 , an execution error is also 
signaled. 

Effect of Argument Error 

E ~ A/cos 2 x, e ~ 2A/sin 2x for tan x. Thus, near the singularities x = (k + Vz )ir, 
where k is an integer, neither absolute error control nor relative error control can 
be maintained. This is also true for cotan x, where x = k-w and k is an integer. 

Performance Statistics 

Performance statistics for the tangent function of the single-precision tangent/ 

cotangent subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 


Maximum 

Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


lxl< — 
4 


4.02X10"° 


1.23 XI 0" 8 


392 


252 


7T _ 7T 


5.48X10"° 


(6.45X10" 8 )* 


470 


304 


-f-<ixi^io 


6.40X10" 8 


(8.53X10 -8 )* 


457 


295 


10<lxl^l00 


6.85X10" 8 


(9.97X10 -8 )* 


458 


296 


*Note: The figures cited as the maximum relative errors are those encountered among 2500 random samples 
in the respective ran«es. For all the nerfect arnuments in the full ranae (leaitimate under the standard 
error control), the maximum relative error is estimated to be 2X10" . 



Performance statistics for the cotangent function of the tangent/cotangent sub- 
routine are as follows : 



Argument 
Range 


Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 
Relative Error 


Average Speed in 
Microseconds 


7090 


7094 


4 


4.75 X10 -9 


1.43X10 -3 


408 


264 


v ^ 3tt 


1.23 XI -8 


(5.39X10 -7 )* 


459 


298 


37r ^ ^ 
— <ixi^io 

4 


6.37 X10 -9 


(2.17 X10 -8 )* 


470 


306 


*Note: The figures cited as the maximum relative errors are those encountered among 2500 random samples 
in the respective ranges. For all the perfect arguments in the full range (legitimate under the standard 
error control), the maximum relative error is estimated to be 2X10"'. 



The sample arguments upon which the above statistics are based were distributed 
uniformly over the specified range. 
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Arctangent — FATN 

Algorithm 
1. Use 

arctan( — x) = — arctan(x), 



fe) 



"2~ — arctan ( | x | ) 



arctan 
Assume < x < 1. 

2. If [tan( 15° ) ] < x < 1, reduce further to the range | x | < [tan ( 15° ) ] by using 

arctan (x) = 30° + arctan (x), where x = y/S — 



x+ V3~ 
3. By transforming the Taylor series into a continued fraction, we obtain 



arctan (x) = x 



1 5 

3 5 



(4) (5) 
(7) (7) (9) 



43 



+ x~ 2 — 
7 7.11 

where w abbreviates further terms. 
Dropping w and rewriting the formula, we get 



+ x~ 2 + w 



arctan 



(*) = x [_ 



64 



x 2 + 



(41) (64) 



(3) (5 2 ) (7 2 ) (53) (7 2 ) 

(3 5 ) (13) (79) 



+ 



(5 4 ) (7») 



x 2 + 



34063 



(3) (5) (13) (79) 



(14641) (1100) 
_ (3 2 ) (7) (13 2 ) (79 2 ) 
(11) (389) 



■] 



x 2 + 



(3) (13) (79) 

For |x| < [tan(15 )], the maximum relative error of this approximation is 
6 X 10-". 

4. Fixed-point computation is used to minimize truncation errors. 

5. atan2 provides the extended answer range — x< y <ir, depending on the 
combination of signs of the two arguments. 

Effect of Argument Error 

E ~ A/(l + x 2 ). For small x, c ~ 8; and as x becomes large, the effect of 8 on e 
diminishes. 

Performance Statistics 

Performance statistics for the single-precision arctangent subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M( C ) 


Average Speed in 
Microseconds 


7090 


7094 


The entire range 


2.93 XI -8 


1.39X10 -8 


419 


269 



The sample arguments upon which the above statistics are based were tangents 
of uniformly distributed numbers between — r- and -^-(i.e., the argument sample 
was such that function values were uniformly distributed over the answer range ) . 
Arcsine/ Arccosine — FA5C 
Algorithm 

1. If < x < Vz, compute arcsin(x) by use of the Chebyshev interpolation 
polynomial of degree 5 over this range. 
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2. If V2 < x < 1, 



arcsin(x) = -^ - 2 arcsin I -J * o * ) ' 

Since in this range we have < .J — <r^~< ^ ^ is case is reduced to that of item 1 
above. 

3. If < x < 1, 

arccos (x) = -z — arcsin(x). 

This reduces the case of arccosine to that of arcsine. 

4. If — 1 < x < 0, use arcsin(x) = — arcsin ( — x) and arccos(x) = tt 
— arccos ( — x) to reduce to the earlier cases. 

5. The routine fsqr is used in item 2 above. 

Effect of Argument Error. 

E ~ A/yi — x 2 . Thus, for small x, E ~ A. For arsin with small x, e ~ S. Toward 

the limit of the range, a small argument error causes a substantial error in the 

answer. 

V o/Anrrnnrtrp. fitn.t.fatir.s 

Performance statistics for the arcsine function of the single-precision arcsine/ 
arccosine subroutine are as follows : 



Argument 
Range 


Root-Mea n-Sq ua re 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M( 6 ) 


Average Speed in 
Microseconds 


7090 


7094 


lxl<l 


5.47 XIO -9 


3.1 5 X TO -8 


533 


286 



Performance statistics for the arccosine function of the single-precision arcsine/ 
arccosine subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 

<r(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


IxKl 


5.54 X TO" 9 


1.98X10" 8 


545 


291 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 

Hyperbolic Sine/Cosine — F5CH 
Algorithm 

gX _j_ g — X 

1. cosh(x) = p . 

2. If I x I > 0.3465736, use 

e* - e~ x 



sinh(x) = 

3. If I x I < 0.3465736, use 

/y*S a-O /*-T 

sinh(x) — x + "3r + "5r + "7r- 
The maximum relative error of this approximation is 6 X 10 _] 

4. This routine uses the subroutine fxpf. 
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Effect of Argument Error 

For the hyperbolic sine function, 

A 2 
E ~ A • coshx H — — sinhx, e . 

For the hyperbolic cosine function, 



A • cothx + 



A • sinhx + 



A 2 



coshx, e rw a • tanhx + 



A 2 



In particular, for the hyperbolic cosine function, e ~ A over the entire range. On 
the other hand, for the hyperbolic sine function with small value of x, e — < 8. 

Performance Statistics 

Performance statistics for the hyperbolic sine function of the single-precision 
hyperbolic sine/cosine subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 
Relative Error 

0(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


1x1^0.3466 


5.36 X10 -9 


1.42 XI (T 8 


262 


153 


0.3466<lxl<10 


4.79 xirr 9 


2.61 XI cr 8 


446 


299 



Performance statistics for the hyperbolic cosine function of the single-precision 
nyperbolic sine/cosine subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 
Relative Error 

(7(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


lxl<10 


4.41 XI 0" 9 


1.35 X10 -8 


426 


285 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 

Hyperbolic Tangent — FTNH 

Algorithm 

1. For | x | < 0.5493, use the modified continued fraction 

tanh(z) =-y- + — + -=-+— + 



9.02743 



The maximum relative error of this approximation is 4 X 10 _9 . 
2. For 0.5493 < x < 10.4, use 

2 



tanh(a:) = 1 — 



+ 1 



The routine fxpf is used in this step. 

3. For 10.4 < x, give 
tanh(x) = 1. 

4. For x < - 0.5493, use 
tanh(— x) = — tanh(x). 

Effect of an Argument Error 

E ~ (1 - tanh 2 x) A, e ~ 2 A/sinh 2x. Thus, for small x, €~S, and as x gets larger, 

the effect of 8 on e diminishes. 
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Performance Statistics 

Performance statistics for the single-precision hyperbolic tangent subroutine are 

as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 
Relative Error 

<r(e) 


Maximum 
Relative Error 


Average Speed in 
Microseconds 


7090 


7094 


lxl^Q.5493 


5.70 X TO" 9 


1.43X10 -8 


349 


228 


0.5493<lxl^l0.4 


2.63 X10' 9 


1.45X10 -8 


438 


292 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 

Error Function — FERF 

Algorithm 

1. Erf(-x) = -Erf(x). 

Assume x > now. 

2. If x > 4.17, 
Erf(x) ss 1. 

3. If 4.17 > x > 1.51, use the following Gaussian type continued fraction: 

2 



l-Erf(x) = 

/ 



f 



e~ u2 du 



e~"du = e— [ — 

L x 2 + 0.5 - x 2 

(n — V2)n 



0.5 



^ e -aj»r 0-5 X 

\_x 2 + 0.5 - 



-x 2 + 2n+ y 2 - 
0.5 3 



+ 2.5 - x 2 + 4.5 

r ...j 



7.5 



10.803 



)3 "I /♦ 
.269 J ' 



x 2 + 2.5 - x 2 + 4.5 - x 2 + 6.5 - x 2 + 4 
The two constants in the last term are obtained by requiring that the formula 
give the exact values at x = V2.3125 and x = V2-75. 
The maximum absolute error of this approximation (*) is 1.1 X 10 -9 . 

4. If 1.51 > x > 0, use the continued fraction obtained in the following way: 
Transform the Taylor expansion of Erf into a continued fraction ( Wall, page 196 ) 
as follows: 



2x 



Erf(x) 



= 1 - 



+ 



= 1 - 



+ 



3 ' 2!5 

1.0281x 2 
x 2 + 10.216 

31.228 



+ 



+ 



+ 



3!7 ' 4!9 

-167.17 
x 2 + 9.8103 

64.244 



+ 



201.39 



x 2 + 11.570 



x 2 - 1.7730 " x 2 + 5.578 + w(x) 

The constants in the last formula are approximate. 

Finally, drop w(x) and instead modify the two constants of the last term so that 
the formula is exact at x = 1 and x = V2. The maximum relative error of the 
formula obtained this way is 2 X 10 -9 . 

5. Fixed-point computation is employed to minimize truncation errors. This 
routine uses the exponential subroutine fxpf. 
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Effect of Argument Error 

E~A-e~ x2 . As the magnitude of the argument increases away from 1, the effect 

of an argument error on the final accuracy diminishes rapidly. For small x, e~8. 

Performance Statistics 

Performance statistics for the single-precision error function subroutine are as 
follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 

er(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 7094 


1x1^4 


3.20 X10" 9 


1.27XKT 8 


681 438 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 

Gamma /Loggamma — FGAM 

Algorithm 

1. If 0<x<2 -127 , for algama use 
log[r(x)] = -log(x). 

2. If 2 _127 <x<4, reduce the case to l<x<2, using 

x[r(x)]=r(x+l). 

Compute r(x) for l<x<2, using a continued fraction obtained in the following 
manner: 

For l<x<2, 



*J O 

00 



e-H x - l dt 



2 k + 1 ak 



(x-1.5) fc (*) 



%J O 



where: a k = i [\ og (t)] k ( e - t2 )t 2 dt. 



a =V4:V^', 

a t =0.80845993X10-2, 
a 2 i= - 0.1628 X10 10 . 
By transforming the formula ( * ) into a continued fraction, we obtain 



r(z+1.5)= ** 
where: 



z+fo 



+ 



z+fa 



z+fti z+(3 5 +w(z) 



/**) 



«x= -1.2581927 

a 2 = 33.814358 

a 3 = 59.285853 

a 4 = -3.6512651 

a 5 = 6.0985782 



/3 1 =- 11.746649 

/8 2 = -4.8326355 

£ 3 = 8.1171874 

/3 4 = 0.20317850 

£ 5 = 1.4063097 

Finally, drop w(z) in formula (**) and compensate for it by modifying the con- 
stants /? 4 , a 5 , £ 5 to obtain an approximation formula accurate to within absolute 
error of 2.3 X10- 9 . 

3. If 2 127 <x<4 for algama, compute log [r(x)J by first computing r(x) as 
in item 2 and then taking the logarithm of the result. 

4. If 4 < x < 1.54926 X 2 120 , compute log [r(x)] as follows: 
log[r(x)] -x[log(x) - 1] - y 2 log(x) + %log(27r) + F(x) 
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where: 

F(x)=0,ifx>2 12 . 

F(x)s l 



+ 



■,ifx<2 12 . 



12x 360X 3 ' 1260x 5 1760x 7 

This formula is the result of economizing Stirling's asymptotic series. For the 
range considered, its absolute error is less than 2.1 X 10 -9 . 

5. If 4 < x < 34.843, compute r(x) by first computing log[r(x)] as in item 4 
and then taking its exponential base e. 

6. The routines flog and fxpf are used by this subroutine. 

Effect of Argument Error 

n...-n /..\ .t./„\ . a . — a c™ i^rr t(~\ v. ■. ^, it ( *} • a wV>prpi & is the dieramma 

function. 

For-^-<x<3, -2 < * (x) < 1, and E ~ A for log r (x). 

However, since x = 1 and x = 2 are zeros of log r(x), even a small 8 can cause 
a substantial e in this interval. 

For large values of x, * (x) ~ log x. Hence, for r(x), e ~ 8 • x • logx. This 
shows that even the round-off error of the argument contributes greatly to the 
relative error of the answer. On the other hand, for log r(x) with large value of 
x, £ ~ 8. 

Performance Statistics 

Performance statistics for the gamma function of the single-precision gamma/ 
loggamma subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


2" m <x<l 


4.55 xirr 9 


1.22X10 -8 


474 


316 


l<x<2 


2.51 X TO" 9 


6.16 X10' 9 


435 


289 


2<x<4 


4.76 XIO -9 


1.59X10 -8 


519 


335 


4<x<10 


6.03 xirr 8 


2.26 X10 -7 


1110 


676 


10<x<34 


3.18X10" 7 


1.27X10" 6 


1110 


678 



Performance statistics for the loggamma function of the single-precision gamma/ 
loggamma subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 

Absolute Error 

,(E) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


^<x<3 


1.02X2 -28 


1.72X2" 27 


858 


532 



Argument 
Range 


Root-Mea n-Sq ua re 
Relative Error 

<r(e) 


Maximum 

Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


0<x<^" 


5.09 X10' 9 


1.72X10" 8 


871 


544 


3<x<4 


5.87 X10" 8 


2.43 XI 0" 8 


945 


579 


4^x<10 


7.81 XI -9 


2.67 X10 -8 


808 


480 


10<x<100 


6.53 XI 0' 9 


2.09 X10 -8 


811 


485 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 
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Double-Precision Subroutines 

The following information describes double-precision subroutines listed in Fig- 
ure 25B. 

Square Root — FDSQ 

Algorithm 

1. Write 

x = (2 2p - q )m, where p is an integer, q = or 1, and V2 < m < 1. 
Then 

V* = 2p[ V(2-«)m] . 

2. Take the first approximation y to be 



?/o 



yo 






The relative error of t/ is less than 2~ 4 . 
3. Apply the Newton-Raphson iteration 

1 / * \ 

J/n+i 2~\^ n+ u / ^ times to yo> 3 times in single precision and the 

last time in double precision: 

The maximum relative error of y z is 2~ 53 . 

Effect of Argument Error 

1/ n 

£^72 0. 

Performance Statistics 

Performance statistics for the double-precision square root subroutine are as 
follows: 



Argument 




Root-Mea n-Sq ua re 
Relative Error 

<7(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


Range 


7090 


7094 


10- 80 ^x<10 37 


7090 


4.26 X TO -17 


1. 59 X10' 16 


448 




7094 


4.03 X10~ 17 


1.56 XI -16 




220 


*For arguments that are less than 10 -30 , speed is substantially slower because of floating-point underflow. 
For accuracy in this range, see the section "Alternate 7094 Floating-Point Trap Subroutine." 



The sample arguments on which the above statistics are based were exponentially 
distributed over the specified range. 

Exponential — FDXP 
Algorithm 

1. e x = 2 V , where y = x(log 2 e). 
Write 

V — 2/i + */2, where y 1 is the integer part and y 2 is the fraction part. 
Define 

% = Vi, z 2 = y 2 , if y > 0. 
*i = Mi - 1, *2 = y 2 + 1, if y < 0. 
Then 

2v = 2* 1 (2**), where z 1 is an integer and < z 2 < 1. 

2. 2 2 for < z 2 < 1 is computed by the use of the Chebyshev interpolation 
polynomial of degree 11 for the interval. The maximum relative error of this 
polynomial is 2 -57 . 

3. If x < -89.415987, is given as the answer. 
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Effect of Argument Error 

£ ~ A. Since A = 8 • x, for the larger value of x, even the round-off error of the 

argument causes a substantial relative error in the answer. 

Performance Statistics 

Performance statistics for the double-precision exponential subroutine are as 

follows: 



Argument 




Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 
Relative Error 

M( 6 ) 


Average Speed in 
Microseconds 


Range 


7090 


7094 


0<x<l 


7090 


4.24 X10" 17 


1.68X10 -16 


3016 




7094 


3.74 X10 -17 


1.07X10"" 16 




559 


-70.0<x<88.028 


7090 


4.82 X TO -17 


1.96X10 -16 


3021 




7094 


4.38 X10 -17 


1.39X10 -16 




564 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 

Logarithm — FDLG 

Algorithm 
1. Write 

x = (2 n )m, where n is the exponent and Vz ^ m < 1. 
Define the base value F as 



F = V2, where V2 < m < 



V2 



F = 1, where ^IA < m< 1. 
Let z = r-^r . Then 



m 



m + F 

= F ( 1±±\ and I z I < 0.1716. 
\ 1 - z / 



log (x) = n [log(2)] + log(F) + log(l±ii). 

log(F) = -log(2),where^<m<-^-. 
log (F) = 0, where ^ 2 < w < 1. 
2. log( X + * ) = 2z (l+*L + iL + . . . \ =z (co + c x z 2 + . . . + c 7 z 14 ), 

where coefficients c ,c u . . , c 7 are obtained by Chebyshev interpolation. 
The maximum relative error of this approximation is 2 -59 - 5 . 

E^ect o^ Argument Error 

E ~ 8. In particular, if 8 is the round-off error of the argument, say 8 ^ 5.6 X 10 -17 , 
then E ^ 5.6 X 10 -17 . This means that if the argument is close to 1, the relative 
error can be very large, since the function value is very small at that point. 

Performance Statistics 

Performance statistics for the natural logarithm function of the double-precision 

logarithm subroutine are as follows: 
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Argument 
Range 




Root-Mean-Square 

Absolute Error 

,(E) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


2^*0 


7090 


1.30X2" 55 


1.64X2- 53 


2723 




7094 


1.76X2 -68 


1.89X2- 64 




463 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 



Argument 




Root-Mean-Square 
Relative Error 

(7(e) 


Maximum 

Relative Error 

M( e ) 


Average Speed in 
Microseconds 


Range 


7090 


7094 


Full range exclud- 
ing the interval 

1 
< T .2) 


7090 


9.65 X10 -17 


2.95X10 -18 


2736 




7094 


6.09 X10 -17 


1.80X10 -19 




474 



The sample arguments on which the above statistics are based were exponentially 
distributed over the specified range. 

Performance statistics for the common logarithm function of the double-precision 
logarithm subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 

Absolute Error 

(r(E) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


Y<x<2 


7090 


1.84 X2" M 


1.12X2 -53 


2886 




7094 


1.66X2 -56 


1.64X2"** 




489 



The sample arguments upon which the above statistics are based were uniformly 
distributed over the specified range. 



Argument 




Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M( e ) 


Average Speed in 
Microseconds 


Range 


7090 


7094 


All positive num- 
bers outside 


7090 


1.18X10"™ 


4.46 X10 -16 


2899 




7094 


9.12 X10 -17 


3.31 XI 0" 18 




500 



The sample arguments upon which the above statistics are based were expo- 
nentially distributed over the specified range. 

Sine/Cosine — FDSC 

Algorithm 

1. If cos(x) is desired, reduce the case to a sine function by 
cos(x) = sin I JL — x |. 

2. If x < 0, use 
sin(-x) = — sin(x). 

Assume x > 0. If | x | < 2~ 26 , give x as the answer. 

3. Divide x by — r- and separate the integer part q x and the fraction part q 2 of 
the quotient. 

Let q = q x [modulo 8]. Then 

sin(x) = sin (^-<7o + -^- q 2 j ■ 
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or cos 



4. Further reduce the case to the computation of either sin I — r I 
( ~T r / w ^ — r — 1 by the formulas 
in I -j- (4 + <7o) +"J<72 = -sin (^^o+Y^ 2 ) > where < g < 3. 

in VT + T? 2 ) = ^Lt* 1 ~ q ^\- 

in ( — + — q 2 I = cos ( — qf 2 ) • 
\ a * ' / \ * / 

(3x 7T \ ["ff ~] 

- r + T , 2 j = sin|_ T (l-< ?2 )J. 



sin I 



sin I 



\ 2 
sin 
5. For < r < 1, 



sin 






S r + S^ + S 2 1* + . . . . + S 6 r 13 . 



1 + Cif 2 + Csf 4 + . . . . + C 6 r 12 . 



Coefficients S , . . . . , S 6 are obtained by Chebyshev interpolation over the range 
< f < 1, and the coefficients C , . . . . , C 6 are obtained by Chebyshev interpola- 
tion over the range —0.01 < r < 1. 

The maximum relative error of the sine approximation is 2~ 58 . The maximum rela- 
tive error of the cosine approximation is 2 -54 . 

Effect of Argument Error 

E ~ A. As the argument gets larger, A grows, and since the function value is peri- 
odically diminishing, no consistent relative error control can be maintained outside 

the principal range I — o~ > ~o~ I • This observation holds true for cosine as well. 



T'Tj 



Performance Statistics 

Performance statistics for the sine function of the double-precision sine/cosine 

subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 

Absolute Error 

«r(E) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


lxl^ 2 


7090 


1.85X2 -55 


1.75X2 - ™ 


2141 




7094 


1.1 2 X2" 54 


J-B2 




414 


2 <lxl^l0 


7090 


1.63X2 -52 


1.52X2""" 


2184 




7094 


1.16X2" 52 


1.32X2" 30 




441 


10<lxl<100 


7090 


1.50X2 -49 


1.42 X2 -48 


2180 




7094 


1.08X2"" 


1.21X2~* T 




441 



Argument 




Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M(c) 


Average Speed in 
Microseconds 


Range 


7090 


7094 


Ixl^y 


7090 


9.14X10" 17 


4.72 X10 -16 


2141 




7094 


9.08 X10" 17 


3.81 XI -19 




414 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 
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Performance statistics for the cosine function of the double-precision sine/cosine 
subroutine are as follows: 



Argument 
Range 




Root-Mea n-Sq uare 
Absolute Error 

*( E ) 


Maximum 
Absolute Error 

M(E) 


Average Speed in 
Microseconds 


7090 


7094 


0<X^7T 


7090 


1.26X2" 54 


1.05X2" 52 


2241 




7094 


1.52X2 -54 


1.14X2 -62 




427 


-20<x<0and 

7T<X<20 


7090 


1.21X2 -50 


1.57X2 - * 8 


2280 




7094 


1.63X2 -62 


1.33 X2 -48 




453 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 

Arctangent — FDAT 
Algorithm 

1. Reduce the general case to < x < 1 by using the following formulas: 
arctan(— x) = — arctan(x). 



arctan 



(*)- 



arctan( \x\). 



2. Then reduce the case further to I x I < tan/ 15° ) bv nsinsr 

i I — \ - - 1 - j o 

(V3)a- 1 



arctan(x) = 30° + arctan t x + ^3 J,iftan(15°) < x < tan(45°). 

tan(15°), a continued fraction approximation of 



3. For the basic range | x 
the following form is used: 



arctan(x) _ .. 
x 



<XiX* 



Pi + x 2 



«2 



as 



+ 



a 4 



(*) 



Pi + x 2 fa + X 2 ' fa + X 2 

This formula can be derived by transforming the Taylor series into the following 
fraction: 



arctan(x) _, 

x 3 



+ x- 



5 ' " (5)(9) 

(4)(T»)(3) 
(5)(11)(13«) 



(3)(4) (5 2 )(2M 

(5 2 )(7) (7)(9 2 )(11) 

(9)(13) " 



23 



(3)(37) 



+ x~ 2 + w 



(13) (17) 

As the approximation of the value to = w(x), pick -0.00398. When we rewrite 
the above fraction with this value of to, we obtain the formula ( * ) . 
The maximum relative error of the formula ( * ) is less than 2~ 55 . 

4. datan2 provides the extended answer range — tt < y < v, depending on the 
combination of signs of the two arguments. 

Effect of Argument Error: 

E ~ A/(l + x 2 ). For small x, e ~ 8; and as x becomes large, the effect of 8 on e 
diminishes. 

Performance Statistics 

Performance statistics for the double-precision arctangent subroutine are as 
follows: 



194 







Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M (E) 


Average Speed in 
Microseconds 


Argument 
Range 


7090 


7094 


Full range 


7090 


6.47 X10 -17 


2.21 XI 0' 16 


2739 




7094 


6.61 X TO" 17 


3.92 XI -1 * 




548 



The sample arguments on which the above statistics are based were tangents of 
random numbers uniformly distributed over r— , — ~— (i.e., the argument 

sample was such that the function values were uniformly distributed over the 
answer range). 

Complex Subroutines 

The following information describes complex subroutines listed in Figure 25C. 

Square Root — FCSQ 

Algorithm 
1. Write 



V x + iy = | + i 7]. 
2. Ifs> + 0,use 



^ 



i = 



- JL. 
r '~ 2£ ■ 

3. Ifx< -0,use 

> = y 

* 2n " 



+ [ x + iy 



, , I I x I + I x + iy I 
V = sgn(y) yj- i — ! 2 • 

Thus, if x < 0, the case y = —0 is differentiated from the case y = +0. That is, 

lim 



V* — Oz = 



V* + 0i = 



lim 



V* — e i. 



yx + ei. 



4. If in the foregoing computation — y — < 2- 129 , then + Oi is given 

as the answer. 

5. The routines fsqr and fcab are used by this subroutine. 
Limitation: If | x \ + | x + iy \ > 2 127 , floating-point overflow is caused. 

Effect of Argument Error 

lix + iy = r • e i?l and V* + iy = R ■ e iH , then e(R) ~ ¥2 8(f) ande(H) ~ S(/i). 

Performance Statistics 

Performance statistics for the complex square root subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 

Relative Error 

<r(e) 


Maximum 

Relative Error 

M( € ) 


Average Speed in 
Microseconds 


7090 


7094 


lQ-^lxi + ixsKlO 37 


4.31X10 -9 


1.44X10 -8 


821 


503 



The distribution of sample arguments upon which the above statistics are based 
is radially exponential and is uniform around the origin. 
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Exponential — FCXP 

Algorithm 

I e x+iy = e x . cos (y) + te j • sin (y). 

2. The routines fxpf and fscn are used by the subroutine. 

Effect of Argument Error 

li e *+iy = R(e«*),thenH = yande(R) - A(x). 

Performance Statistics 

Performance statistics for the complex exponential subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 

<r(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


lxil^85, Ixsl^lO 


6.64X10° 


1.97XKT 8 


1345 


835 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 

Natural Logarithm — FCLG 

Algorithm 

1. Write 

log(x + iy) = $ + i v . 
Then in the sense of atan2, 
I = log( \x + iy\ ) and 

r? = arctan — . 
x 

2. This routine differentiates the argument x — Oi from the argument x +0i, 
That is, 

log(x-0f)= € ^ Q \0g(x-ei). 

log(x + 0i)= J^QlogCx + €•). 

3. The routines fcab, flog, and fatn are used by this subroutine. 
Limitation: If | x + iy | > 2 127 , floating-point overflow is caused. 

Effect of Argument Error 

lix + iy = r • e ih and log (x + iy) = £ + i v , then h = v and E(£) ~ 8(r). 
When the argument is near 1 + Oi, the answer is almost 0, and therefore a small 
S can cause a large £. 

Performance Statistics 

Performance statistics for the complex logarithm subroutine are as follows: 



Argument 
Range 


Root-Mea n-Sq ua re 

Relative Error 

<r(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


Full range, except 
the immediate neigh- 
borhood of 1+0/. 


3.45X10" 


3.03 X10" 8 


1469 


906 



The distribution of sample arguments on which the above statistics are based is 
radially exponential and is uniform around the origin. 
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Sine/Cosine — FCSC 



Alpnrithm- 
— o~ • 

1. sin(x 4- iy) = [sin(x)] [cosh(t/)] + [i] [cos(x)] [sinh(f/)] 
cos(x + iy) = [cos(x)] [cosh(t/)j — [i] [sin(x)] [sinh(y)] 

2. The routines fscn and fsch are used by the subroutine. 

Effect of Argument Error 

Combine the effects of the sine and cosine functions of the single-precision sine/ 
cosine subroutine with the hyperbolic sine and cosine functions of the single- 
precision hyperbolic sine/cosine subroutine according to step 1, in the algorithm 

Performance Statistics 

Performance statistics for the sine function of the complex sine/cosine subroutine 
are as follows: 



Argument 
Range 


Root-Mean-Square 

Relative Error 

<r(«) 


Maximum 

Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


Ixjj^lO, ix 2 i^l 


7.53 X10 -8 


(2.81X10 _S ) 


1868 


1169 


Note: The maximum relative error cited here is based upon a set of 2500 random samples in the range. 
In the immediate neighborhood of the points n7r + 0i, n=±l, ±2,..., the relative error can be quite 
high, although the absolute errors are small there. For the same value of X2, the relative error increases 
with !xil. For the same value of xi, the relative error stays substantially constant as Ixal increases. 



Performance Statistics 

Performance statistics for the cosine function of the complex sine/cosine subrou- 
tine are as follows: 



Argument 
Range 


Root-Mean-Square 

Relative Error 

*(e) 


Maximum 

Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


lxi!<10.- !x 2 !<l 


7 AA v i rr 9 


(2.72 X 1 Q -8 ^ 


1871 


1 lAO 


Note: The maximum relative error cited here is based upon a set of 2500 random samples in the range. 
In the immediate neighborhood of the points {n + V2)ir + 0i, n = 0, ±1, ±2 . . . , the relative error can be 
quite high, although the absolute errors are small there. For the same value of x a , the relative error increases 
with Ixil. For the same value of xi, the relative error stays substantially constant as U2I increases. 



The sample arguments on which the above statistics are based were uniformly 
distributed over the specified range. 

Absolute Value — FCAB 

Algorithm 

1 If ' x ' > I u ' 

I x + yi j = I x I J 1 + (— ) 2 + 0/. 
2- If j y I > I x I, 



x + yi\ = \y 



+ 0i. 



3. The routine fsqr is used by this subroutine. 

Note: If the result is greater than Q, the floating-point overflow is caused. 
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Performance Statistics 

Performance statistics for the complex absolute value subroutine are as follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 

<r(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


lCr^lxi + ixol^lO 37 


5.80 xirr 9 


2.44 X10" 8 


421 


250 



The distribution of sample arguments on which the above statistics are based is 
radially exponential and is uniform around the origin. 

Arithmetic — FCAS 

Algorithm 

1. (a + bi) ± (c + di) = (a ± c) + (b ± d)i 

2. (a + bi) X (c + di) = (ac - bd) + (ad + bc)i 

3. If | c | > | d \, 

■ad/c 2 + b/c 



i _i_ i.-\ • / j_ 7-\ fl/c + bd/c 2 
(a + bi) — (c + di) = , . , T , v „ + 



XI. 



1 + (d/c) 2 1 + (d/c) 2 

If | d | > | c |, then reduce to the case above by transforming (a + bi) ■+■ (c + di) 

= (b — ai) -r- ( d — ci). 

Note: When the magnitude of the result is close to O, a floating-point overflow 
is possible. When the magnitude of the result is close to the underflow threshold, 

■M-1,0 nnnni-nnw r\r 4-rnn onc^im** rlimirncnoc 

LJ-J^ C*.V_,^Ci.l CfOV C/JL LHV> U11JVV KsX VAJLJ. J.lAA-tXO-1 AWO . 

Performance Statistics 

Performance statistics for the multiply function of the complex arithmetic subrou- 
tine are as follows: 



Argument 
Range 


Root-Mean-Square 
Relative Error 

5(e) 


Maximum 
Relative Error 


Average Speed in 
Microseconds 


7090 


7094 


For pairs of operands 
which are away from 
the overflow or under- 
flow thresholds 


1.09X10" 8 


2.62 XT s 


324 


174 



Performance statistics for the divide function of the complex arithmetic subrou- 
tine are as follows: 



Argument 
Range 


Root-Mean-Square 

Relative Error 

8(e) 


Maximum 
Relative Error 

M(e) 


Average Speed in 
Microseconds 


7090 


7094 


For pairs of operands 
which are away from 
the overflow or under- 
flow thresholds 


1.3X10" 8 


3.23 X TO" 8 


513 


299 



The distribution of sample operands upon which the above statistics are based is 
radially exponential and is uniform around the origin. 

Miscellaneous Subroutines 

The following information describes miscellaneous subroutines listed in Figure 26. 
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Error Control Modification for the FTNC Subroutine — FMTN 

The fmtn subroutine modifies error control of the single precision tangent/ 

cotangent subroutine (ftnc). Its calling sequence is: 

CALL MTAN(fc) 
When the k = 0,1, 2, 3, 4, or 5, the ftnc subroutine is modified to give a minimum 
relative accuracy guarantee of 1/(2 A+2 — 1) for correctly rounded arguments near 
the singularities. When k is greater than 5, the ftnc subroutine is modified to sus- 
pend the accuracy guarantee feature completely; any argument less than 2 20 in 
magnitude (and greater than 2~ 126 for the cotangent function) will be accepted. 
The map programmer can accomplish the same effect as the fmtn subroutine 
by coding the following instructions: 

1. When the accuracy guarantee is to be modified: 

CLA =1 

ALS k 

STO CRIT 

Here k = 0, 1, 2, 3, 4, or 5. Values higher than 5 should not be used. 

2. Where the guarantee is to be eliminated: 

STZ CRIT 

7090 Double-Precision Arithmetic Simulator — FDAS 

The fdas subroutine was designed to perform double-precision addition, multi- 
plication, and division for the 7090 double-precision mathematical functions. Since 
it saves space as a closed subroutine in comparison with macro-expansions of 
double-precision instructions, it is also useful to the map programmer. The fdas 
subroutine cannot be called by Fortran iv or cobol programs. 
The calling sequence for the fdas subroutine is: 



TSX 


entry point, 4 


PZE 


AD1,T1 


PZE 


AD2,T2 



where the entry points are dfad for addition, dfmp for multiplication, and dfdp 
for division. The first operand must be contained in the ac-mq. adi modified by the 
tag ti is the core storage address of the high-order portion of the second operand; 
ad2 modified by the tag T2 is the address of the low-order portion. The fdas sub- 
routine leaves cue resun Oi me cornpui.ai.ion in u.±e ac-mq. 

Note: The fdas algorithms are similar to the macro-expansions of double- 
precision instructions. The subroutine always acts as an extension of the calling 
program, i.e., it does not update system locations. If a floating-point trap occurs 
during its operation, the name printed in an error message is that of the calling 
program, fdas uses only index register 4 and contains no entry point for subtraction. 
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Appendix I: Storage Requirements for FORTRAN IV 
Mathematics Library Subroutines 



The following chart shows the octal and decimal storage requirements for the 
Fortran iv mathematics subroutines. An asterisk beside the name of a subroutine 
indicates that, in the 7090 Subroutine Library, double-precision operations for that 
subroutine will be performed by the fdas subroutine. 

In each pair of figures, the figure to the left of the slash represents the number 
of storage words used in a 7090. The figure to the right of the slash applies to 
a 7094. 



STORAGE REQUIREMENTS 



SUBROUTINE NAME 

FASC 

FATN 

FCAB 

FCAS 

FCLG 

FCSQ 

FCSC 

FCXP 

FDAS (7090 library only) 

FDAT* 

FDSQ 

FDSC* 

FDXP* 

FERF 

FGAM 

FLOG 

FMTN 

FSCH 

FSCN 

FSQR 

FTNC 

FTNH 

FXPF 



OCTAL 


DECIMAL 


131/131 


89/89 


232/232 


154/154 


44/40 


36/32 


115/102 


77/66 


61/60 


49/48 


55/54 


45/44 


163/157 


115/111 


130/125 


88/85 


46/- 


38/- 


314/231 


204/153 


231/170 


153/120 


100/67 


64/55 


250/211 


168/137 


205/170 


133/120 


141/141 


97/97 


302/302 


194/194 


177/177 


127/127 


13/13 


11/11 


121/121 


81/81 


173/173 


123/123 


53/53 


43/43 


222/222 


146/146 


72/72 


58/58 


121/121 


81/81 
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Appendix J: Procedure for Using the 7090 Asterisk Deck 



The 7090 Asterisk Deck generates asterisks if an in- 
sufficient field width is specified in a program using 
the standard 7090 conversion routines. Output through 
the standard 7090/7094 conversion routines is thus 
made consistent with output from the 7094 optional 
conversion routine. 
The deck is used as follows: 

1. Mount the 7090/7094 ibsys Operating System sys- 
tem tape as syslbi on ai. 

2. Mount a tape on A3 containing the Subroutine 
Library as the first file. This tape is made by copying 
the Subroutine Library from Symbolic Tape 1, where 
it is the fifth file. 

u. ncpaic a. tctpc ilutii me ivMj AsrensK uecK ana 
mount the tape as sysini on A2. Press load tape. 



4. The following message should occur: 

$* MOUNT SCRATCH TAPE ON A3 WHEN IT 
UNLOADS. 

Remove the tape containing the Subroutine Library 

fmm A3 cmrl rnnimt o P^^ofnl! 4-r.^c Tk« n niI , "7AOA PICK^A 

iiV111 J. ».v Uiivi liiVUUL tA. ociatVll ICILJI/. X lit/ HOW i\J<J\J/ i \JOT 

ibsys Operating System system tape will be produced 
on A3 when the job is completed. 

5. The following message should now occur; 

$* MOUNT SCRATCH TAPE ON B3 WHEN IT 
UNLOADS. 

Remove B3. This is the new Subroutine Library sym- 
bolic tape. 

6. Mount a scratch tape on B3 and continue. At the 
end of job the tape on A3 will contain the new 7090/ 
7094 ibsys Operating System tape. 
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The definitions in this glossary apply to these terms as 
they are used in this manual. The reader may also 
refer to the IBM Reference Manual, Glossary for In- 
formation Processing, Form C20-8089. 
absolute 

A term referring to specific core storage addresses. 
Absolute text and absolute program refer to machine 
language instructions that can be loaded directly 
into specific areas of core storage for execution. 

AC 

See "register." 

accumulator 
See "register." 

AC-MQ 

See "register." 

alternate unit 



such unit as the result of programmer direction. 

application 
Any single use of a subsystem or user's program. 

argument 
An independent variable. 

assembly 
The process of translating into machine language a 
program coded in a symbolic language that parallels 
machine language coding. 

Assembler 

See "Macro Assembly Program." 

bit 

A binary digit. In 7090/7094 core storage a bit is 
represented by a magnetic core. If the computer 
circuits have made the core positive, the bit is a 
1; if the core is negative, the bit is 0. A bit can be 
represented on external storage such as tape. 

blank common 
A storage area in upper core to provide temporary 
storage for data that will be used by several pro- 
gram segments. The blank common area is lost after 
the job is completed. 

block 
A group of data records, words, or characters. The 
size of a block may be limited by the amount of core 
storage available for buffers or by some inherent 
characteristic of a particular input/output device. 



blocking 

Records are blocked, or grouped together in a buffer, 
in order to increase the average length of the phys- 
ical records being written, thus reducing the process 
time per record, and increasing the total number of 
records that can be written on one unit. 

buffer 

An area of core storage that is used to temporarily 
store information during a transfer of information 
within core storage itself or to or from an input/ 
output device. 

calling sequence 

The instructions and data words that establish the 
linkage to and from a subroutine. 

call transfer vector 

The data words in a calling sequence that contain 
the information used to identify the position of rou- 
tines whose location is out of the regular sequence 
of instructions. 

chaining 

A technique for associating two or more table en- 
tries with each other. A word in each chained entry 
contains the address of the next entry in the chain. 

checksum 

A summation of digits or bits used primarily for 
checking purposes and summed according to an 
arbitrary set of rules. 

closed subroutine 
A subroutine that is a separate routine. To use a 
closed subroutine, the programmer transfers con- 
trol out of his main program into the subroutine. 
The subroutine terminates by transferring back to 
the main program. A closed subroutine is entered 
into only once, and can then be used as often as 
needed by coding in the main program a calling 
sequence that gives the name of the subroutine and 
the desired parameters. 

COBOL 

cobol ( Common Business Oriented Language ) is a 
programming language designed primarily for com- 
mercial data processing. It allows the user to de- 
scribe the processing to be performed in terms 
similar to business English. 

cobol Compiler 
A component of the ibjob Processor that translates 
a cobol program into map language as input to the 
Macro Assembly Program. 



202 



communication word 

A permanent storage location used to transfer infor- 
mation from one set of coding to another. 

compile 

To transform a problem-oriented program into a 
symbolic language that parallels machine language, 
or into machine language itself. 

component 

A part of the ibjob Processor that is called to per- 
form a specific task. For example, the cobol Com- 
piler is called to translate a cobol deck into the 
map language. 

constant addend 
That part of a subscript which is a constant and is 
connected to a variable using an additive operation. 

control dictionary 

The portion of a relocatable binary deck that con- 
tains symbolic information necessary to relocate 
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locations of control sections. 

control section 
A sequence of instructions or data whose name is 
entered in the control dictionary for the program 
deck that contains the control section. It can be re- 
ferred to from outside this program deck and can 
be deleted or replaced with a control section from 
another program deck. 

core storage 

The form of high-speed main storage using mag- 
netic cores that is found in a 7090/7094 Data 
Processing System. 

debug 
To detect, locate, and remove the mistakes from a 
program. 

dictionary 
A table of entries that define symbolic names. 

double-precision 

A term used to describe computations in which the 
arguments are numbers contained in two adjacent 
machine words for greater accuracy. 

embedded blank 

A blank between two characters. 

end-of-file 

An end-of-file refers to a file mark (tape mark) 
which signals the end of a file of information on 
a tape unit. 

entry point 

A location in a program deck to which control can 
be transferred from another program deck. Also 
used to describe the location of the first instruction 
to be executed in a program. 



error-flow trace 
A routine used to determine the logical order of 
program execution that occurred before an error. 
See the "fortran Utility Library" under "Subroutine 
Library Information." 

even location 

A core storage location the address of which is an 
even number. Core storage locations are numbered 
through 32,767. 

even storage feature 

TVio r\rm;ici'nrv i-rvr occicmirirr an (*\rp'r\ iru'ftririTi iTi In- 

structions, double-precision floating-point operands, 
or other data to satisfy machine requirements or to 
increase efficiency of operation. 

execution 

The computer operation performed in response to 
program instructions. 

external storage for text 

Temporary storage areas on a peripheral unit used 
to contain program instructions which cannot be 
contained in main storage during loading. 

file 

A collection of related information. 

file closing 

The termination of input/output operations on a file. 
It often involves the preparation of end-of-file trailer 
labels and rewind operations. 

file control block 

Twelve words in storage containing the control in- 
formation and characteristics of a file to be processed 
by iocs. 

A table of entries that define files. 

file mark 
A special indication on an external storage device 
that informs the program that the end of data has 
been read on the device. A file mark is written by 
the input/output label system after the header label, 
and after the checkpoint recording, if any, and be- 
fore and after the trailer labels of output files. 

file opening 

The initialization of input/output operations on a 
file. This often involves verification of header labels. 

floating-point 

A form of notation wherein numbers are represented 
by a number multiplied by a power of ten. For ex- 
ample, 99.1 would be represented as 9.91 X 10 1 . The 
portion of the number to the left of the multiplica- 
tion sign is the mantissa. The portion to the right is 
the exponent shown as a power of 10. In a 7090/7094 
36-bit machine word the exponent of a floating-point 
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binary number is expressed in the upper eight bits 
as a power of two and the mantissa is contained in 
the remaining portion. 

FORTRAN 

A programming language that closely resembles the 
ordinary language of mathematics and is designed 
primarily for scientific and technical applications. 
Fortran Compiler 
A component of the ibjob Processor that translates 
Fortran iv programs into relocatable binary input 
to the Loader. 

header label 

A record containing common, constant, or identify- 
ing information for a group of records which follow. 
It usually contains a file identification, a creation 
date, and a retention period. 

initialize 

To set an instruction, counter, switch, or address 
to a specific starting condition in preparation for 
operation. 

input editor 
A part of the input/output editor under the ibjob 
Processor which regulates input to the Processor. 

intersystem unit 
An input/output unit that is to be reserved so that 
information may be passed between jobs. 

job 

All card images from one sjob card up to but not 
including the next sjob card. Within a job, one or 
more applications are executed as a logical unit. 

job control 

A component of the ibjob Monitor that supervises 
the overall operations of the Processor and commu- 
nicates with the ibsys System Monitor. 

library 

An organized collection of operating programs, sub- 
routines, and data. 

links, overlay 

Segments into which a program can be divided 
when it exceeds core storage capacity. The main 
link is resident in core storage while a job is being 
executed. Dependent links are stored on external 
storage units and can be brought into core storage 
when needed. See "Overlay Feature of the Loader." 

load 
To take information from auxiliary or external 
storage and place it into core storage. Loading 
under the ibjob Processor consists of combining 
separately assembled program decks and required 
subroutines, establishing an input/output mechanism 
for the program, and placing the program in the 
necessary core storage sequence for execution. 
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load map 
A listing by the Loader of core storage allocation 
just prior to execution of a program. 

Loader 
The component under the ibjob Processor that loads 
programs. 

location counter 

A counter that is incremented by one for each word 
the assembly program generates in the object 
program. 

machine language 

The binary data that can be executed or used di- 
rectly by the processing unit of the 7090/7094. 

Macro Assembly Program 
The component of the ibjob Processor that translates 
map language source programs into either relo- 
catable binary machine language as input to the 
Loader, or absolute binary machine language. Often 
called the Assembler. 

MAP 

A symbolic language that closely parallels machine 
coding on a 7090/7094 machine. 

monitor 
A program or routine to control operation of sev- 
eral other programs or routines. 

MQ 

See "register." 

nucleus (ibsys) 
The portion of the System Monitor that remains in 
core storage at all times during use of the operating 
systems to provide common data areas, pointers, 
tables, and routines. 

object program 
The output from an assembler or compiler, usually 
in machine language. 

off-line 
A term pertaining to operation of input/output de- 
vices or auxiliary equipment not under direct control 
of the central processing unit. 

on-line 
A term pertaining to operation of input/output de- 
vices under direct control of a program being ex- 
ecuted in the central processing unit. 

open subroutine 
A subroutine that is inserted into the normal se- 
quence of a program. Each time an open subroutine 
is used by a program, all of the instructions of that 
subroutine must be repeated. 

operating system 
A collection of monitors, subsystems, data control 
programs, and user's programs that permit unin- 
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origin 

The address of the beginning of a program section. 

overflow 

1. During loading: an operation that transfers to 
an external storage unit the reloctable binary text 
that exceeds its allocated storage area. 

2. During computation: a condition in which a com- 
puted result is too larce for the register(s) used 
to contain it. 

overlay 

The technique of using the same block of core 
storage for two or more program's segments, called 
links, that are executed at different times. These 
links are on external units and are called into core 
storage by the program when needed. 

parameter 

A quantity to which arbitrary values may be 
assigned. 

patch 

An instruction or group of instructions inserted in 
a program to correct or change coding temporarily. 
See "spatch card." 

peripheral 

A term pertaining to operation independent from 
the main computer. 

Polish notation 
A notation used in reducing arithmetic expressions 
into a form suitable for translation by a processor. 

rM*oT-»r»ciHrmincr fpafiirp 

A routine provided by the Processor Monitor that 
causes the next needed component to be positioned 
on the system tape for immediate access. 

process control 

A component of the Processor Monitor that super- 
vises the assembling and compiling of a source 
program. 

processor 

A program that compiles, assembles, and loads a 
program and usually supervises its execution. 

program 

1. A plan for the solution of a problem, including 
data-gathering, processing, and reporting. 

2. A group of related routines that solve a given 
problem. 

program deck 

A section of coding headed by a component control 
card and terminated by an "end" card appropriate 
to the language in which the deck is coded. 



program set 
A set of conti CT uous programs in the same job. 

pseudo-operation 

Any operation available in the map language that 
is not an actual machine operation, special instruc- 
tion, iocs operation, prefix code, or macro-operation. 
It directs the Macro Assembly Program in the 
process of assembly, rather than the computer in 
the process of program execution. 

qualification 
The process of uniquely identifying the symbols 
defined in a given section of a program by append- 
ing another symbol. 

relocatable 

A term referring to core storage addresses that must 
be incremented to absolute addresses before use in 
program execution. A relocatable binary deck is a 
deck coded in machine language that is produced 
by the Fortran rv Compiler or Assembler as Loader 
input. The deck may consist of up to four sections: 
control dictionary, file dictionary, text of program 
instructions, and a dictionary of debugging symbols. 
The location of each instruction in the text section 
is numbered relative to the first instruction in the 
deck. Each reference to an address is also relative. 
Each relative address is incremented to an absolute 
address during the loading process. 

register 

A device used to store data while it is being either 
processed or transferred from one location to an- 
other. The accumulator (also called the ac) con- 
tains the results of single-precision addition and 
subtraction. The multiplier-quotient (mq) contains 
the results of single-precision multiplication and 
division. When used together the combined registers 
(ac-mq) contain the results of double-precision and 
complex computations. Index registers are used to 
contain quantities for address modification and for 
purposes such as the determination of loop exits. 

routine 

A sequence of machine instructions that carry out 
a specific function. 

scatter-loading 
A technique for loading sections of a record into 
different core storage areas. Each record section is 
headed by a separate input/output command. 

single-precision 
A term used to describe computations in which each 
argument is contained in one word. 

source program 
A program written in a problem-oriented or sym- 
bolic language, and which is not in a form that can 
be directly executed by a computer. 
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spill 

An operation during loading that transfers to an 
external storage unit all the text of a relocatable 
binary program. This transfer occurs when the core 
storage area for text is in danger of being overlaid 
by storage areas for other data. 

statement scanner 

A compiler routine which accepts as input a state- 
ment written in symbolic language and classifies 
and performs preliminary processing on the state- 
ment. 

storage map 
A listing by the Fortran iv Compiler or Assembler 
of the relative contents of core storage. 

subroutine 
A set of instructions, taken as a unit, that perform 
a specific programming task. Subroutines are com- 
monly used for such phases of a problem as common 
mathematical procedures (e.g., finding a square 
root), converting data from one form to another, 
and error procedures. The subroutines can be used 
many times over, by one or several programs. 

subsystem 
A major component of the ibsys Operating System, 
such as the ibjob Processor or the Generalized Sort- 
ing Program. 

symbol 

A character or combination of characters used to 
represent the address of a storage location, an in- 
put/output device, or any other program parameter. 
An immediate symbol is assigned a specific value 
during the first pass of the assembly program. A real 
symbol is a symbol defined in the deck in which it 



appears. A virtual symbol is a symbol that is not 
defined in the deck in which it appears. 

symbolic language 

The defined set of characters and the rules for com- 
bining them into meaningful communication that 
permits the programmer to represent the maohine 
locations and instructions by recognizable names 
and symbols, e.g., the map language. 

trailer label 
A record with identification and control data related 
to previous records of a labeled file. It occurs at the 
end of the file, or at the end of each reel of a multi- 
reel labeled file. 

trap 

An interruption of program execution in response 
to a specific condition, such as underflow or over- 
flow. A trap is usually followed by a transfer to a 
routine to investigate and take action on the con- 
dition causing the trap. 

underflow 

A condition in which a computed result is too small 

for the register(s) used to contain it. 
unit control block 

A nine-word area of core storage describing an 

input/output device connected to the computer, 
utility unit 

A unit that is available for use by the system or by 

the programmer for any purpose. 

word 

In 7090/7094 core storage a set of 36 bits that are 
taken by the computer to express data in binary 
form. A word can be represented on external storage 
such as tape. 
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FORTRAN IV Compiler Information 62 
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Links, overlay 39 
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Loader ( IBLDR ) 29 82 

component control card ' 31 
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relocatable binary text 94 

Loader Information 82 

Load-Time Debugging Processor 25 

actions by the Assembler 80 

actions by the FORTRAN IV Compiler 80 

actions by the Loader 8 o 

compiler routines 8Q 

editor and translator routines 81 

error messages 149 

execution time routines 80 
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object program calls to subroutines 46 
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system subroutines 100 

Subroutine Library Information 100 
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